User Details
- User Since
- Nov 29 2018, 10:03 PM (186 w, 1 d)
Fri, Jun 10
Thu, Jun 9
Fri, Jun 3
Thu, Jun 2
Mon, May 30
There is no good reason imo to have object parenting work differently for curves when there are such things as constraints to achieve the same thing. There is a series of other hidden functionalities baked into the curve object.
Fri, May 27
May 20 2022
Some feedback on the current state:
- For me personally, the way that the brush direction is considered and emphasized doesn't feel right for hair sculpting. For meshes it makes sense, as this is useful to create edges in the surface. For the clumping of hair it makes more sense to be omni-directional imo
- I think the we need a way to scale the brush strength from root to tip along the curves. I'm not sure how that fits into the current design, whether that is a selection thing or a setting of the brush
- I'm not sure about the Clump Radius. I feel like the problems it is trying to resolve should be possible to be resolved better with a different approach when we iterate over the brush
- In my opinion the pinching creates more natural results as points that are further away regularly travel a longer distance per brush sample. Right now they all move at the same speed (assuming a constant falloff). When I adjust the influence to be approximately multiplied by the distance from the cursor the result is more natural imo
May 13 2022
May 12 2022
May 10 2022
May 9 2022
May 3 2022
Apr 28 2022
Thanks for the updates, looks good now from my end!
Apr 26 2022
That was quick, thanks for the patch!
Apr 25 2022
Apr 11 2022
Apr 7 2022
Ah, sorry, I didn't see
Apr 5 2022
Apr 4 2022
Mar 30 2022
Ah, sorry. I searched if there was already a report but didn't find this one.
Yea, that seems to work, thanks! I always found it very unpredictable what an operator actually needs to have overridden, but I guess I should just override everything that could be potentially needed.
But yea, it probably still shouldn't crash. The issue seems to also just be with the lattice modifier from what I have seen.
Mar 23 2022
I'm talking about the default of inputs of the node group for when it's used in another node tree.
I phrased it badly, what I meant was that there the default value should be used regardless. So the default attribute behavior would only affect the modifier version of that node group.
maybe there has to be a bit of discussion on this topic, but I think this makes the most sense.
Mar 22 2022
Small addition: In the case of modifier inputs that would also require to set the default input to be an attribute in the first place.
For outputs that is given, for nodes the input should be passed via node link.
Mar 16 2022
I'm able to reproduce on Linux, this looks like the same issue that I was having.
Mar 9 2022
Mar 2 2022
Beautiful, this is how it should be!
Feb 24 2022
Thanks for looking at this functionality Jacques!
Feb 23 2022
@Henrik Dick (weasel) I tested the patch. It makes an improvement, but it does not seem to fully fix the issue. In the initial example I shared there is still a (smaller)artefact visible that wasn't there before.
I also tested another mesh where it appears to be a regression.
I will update the example file in the task description to include both meshes.
Oh sorry, I missed making the mesh local. I replaced the file
Feb 22 2022
Feb 10 2022
@Hans Goudey (HooglyBoogly) I'm getting a bit lost in what you are proposing. It seems to me that while we are disagreeing on the reasoning an a fundamental level, we are combing to the same conclusions on what this node should look like. That makes it a bit confusing to me.
Feb 7 2022
Feb 1 2022
Hm. This might be personal bias due to my physics background, but to me combining a vector socket from 3 components is fundamentally the same operation regardless of the used coordinate system.
Sure, in the code the cartesian system is used for everything, but I personally would prefer if a more agnostic approach.
Thanks!
Jan 31 2022
I'm now having the strange issue with the provided example video file that when I add it to the sequencer, now the preview without proxy is not matching until I made a first render or changed the timecode.
Jan 28 2022
@Ludvik Koutny (rawalanche) How is the solution you are mentioning different from the 4th one I added in the description? In that you hold the modifier key before you confirm the search choice? That seems to make it a bit opaque to me what the modifier key is actually doing.
Jan 27 2022
Some of my initial thoughts to keep track in this task:
Jan 26 2022
Thanks for the clarification. Then I guess I misunderstood that initially. For me the whole problem are the proxies not matching the original.
Jan 25 2022
Not sure if I'm misunderstanding something. The proxies are indeed causing the issue for me. Without them everything is fine.
Without proxies I do get the warning (not reliably though). Selecting a timecode index method does help indeed.
I don't seem to be getting any warning with the example file that I posted. Maybe I'm expecting something else than is happening? Could you post a screenshot of what it should look like?
Jan 24 2022
I'm not sure I'm 100% up to date with where to cause and fix the issue after the fix that you're proposing.
Having this work by default for new strips sounds acceptable to me. Still, there should be a warning displayed, in my opinion, in cases that we know cause issues.
Jan 21 2022
Okay, that sounds fine to me, thanks!
@Richard Antalik (ISS) I wasn't able to reproduce the issue that you are mentioning with the exact steps you provided. For me the non-proxy preview seems to be consistent with the render here.
But, indeed, the fundamental issue here is not necessarily that the proxies are not matching, but in turn that because of this the render doesn't match the preview. So if there is another source for this issue then that is also part of the problem.
To clarify, though. If your example is a point about frame-perfect matching, then that's also valid, but not nearly as drastic as the issue that I'm describing with the proxies, as here differences can stack up throughout the video for an arbitrary time offset, much greater than a single frame. And fixing this after the fact is nearly impossible, so an edit has to be manually redone in most cases.
Jan 20 2022
This looks good to me! Glad we could come to a conclusion that makes everyone happy :)
Jan 18 2022
Jan 14 2022
The node looks generally good to me! I have a couple of remarks and questions:
Just adding myself as a reviewer to track this. This doesn't regard the code review.
Thanks, I could build it again.
I couldn't apply the patch on yesterday's master for some reason. But here some smaller notes judging from screenshots and code:
Jan 13 2022
Jan 12 2022
This is a big node, so I have a couple of remarks:
Jan 11 2022
I generally agree on the point about predictability, but to me this doesn't apply here.
For me this patch is good to go now :)
I noted my thoughts on this originally in the design task:
Jan 10 2022
Thank you, I think it would be nice to have mote boolean logic in the node!
Thank you for the patch Charlie!
Thanks for the changes!
Jan 7 2022
For usability I would suggest the following definitions:
- Node layout:
- Like Separate/Combine XYZ
- Naming and Scope:
- Components: Radius/Zenith/Azimuth -> R/Theta/Phi
- Maybe this could also be solved with more generic Combine/Separate Vector nodes that can have different 3D coordinate modes. E.g. Cartesian (X/Y/Z) (->default), Spherical (R/Phi/Theta), Cylindrical (Rho,Phi,Z)
- Units: Radians, shown as deg for the UI (same as e.g. Vector Rotate)
- Value Ranges: Phi [-pi, pi], Theta [-pi/2, pi/2]
Cool, thank you!
We chatted about this patch in today's meeting and agreed that the rotation input can be removed.
I just noticed that the Rotation input was a request by @Hans Goudey (HooglyBoogly) :D
I personally don't think that this node needs this functionality itself, as I think usually you would want to use this node for relative rather than absolute transformations and this can be done with a single node afterwards.
But this is not a very crucial point for me.
Sorry, missed this patch for a while!
Jan 6 2022
I just noticed the inconsistency with the mesh editing behaviour when the selection of the extrusion is equal to a full mesh island (?). I'm actually not quite sure what the rules for this are, it does seem a bit arbitrary.
I do think though, that ideally the node behaviour would be consistent with what the operator does.
I do personally like this behaviour with implicit normal offset a lot better!
I might be misunderstanding something here.
Jan 5 2022
I honestly don't think that clamping should be the default for a generic mix node.
I'm actually not even sure it should be an option in the node at all.
For MixRGB specifically it makes sense for the workflow, to avoid colors outside of 0/1. For generic mix operations of value/vector maps though I don't really see that much inherent value in this input.