pronouns: she/her
User Details
- User Since
- Mar 2 2019, 7:01 AM (173 w, 10 h)
Apr 20 2022
Mar 3 2022
Feb 4 2022
Sep 22 2021
Sep 21 2021
Aug 15 2021
Jul 5 2021
I feel I should resign from this one and put it up for grabs (not sure how) I am not keeping up with things. A lot has moved ahead and I feel as though this task can be better tackled with a more clear design from a core team.
Lost track of blender development on geo nodes. It seems it is changing drastically and I can no-longer keep up.
Jun 25 2021
Jun 23 2021
Jun 18 2021
May 22 2021
May 14 2021
Amazing!!! I feel as though the overlay shader needs an option for tile recursions to better show smaller distortions. Maybe something like this?
(mockup in gimp, every time decrease by 1/4th and overlay with exponent drop in strength)May 13 2021
Holy mother of callstack batman!
May 12 2021
handle_position_a -- better name?
handle_position_b -- better name?
May 8 2021
May 3 2021
Moving back to community tasks as I moved it after a meeting to be wrapped up for 2.93 but due to technical issues and the solution feeling incomplete this was not done to avoid a rushed product. I feel like shifting sands around the codebase and bigger priorities around geometry nodes have pushed this back a bit. I would like to return to this when more decisions around volume modeling are made and it fits in more with ongoing design tasks.
May 1 2021
Apr 30 2021
Your GPU is quite old and appears to be significantly out of date. The last driver update released for your card appears to be version 391.35 (released on Tue Mar 27, 2018) while you are using 382.05 which is significantly older. Try updating your graphics driver and seeing if that fixes your issue. (while I was gathering info someone else answered)
Apr 29 2021
Apr 26 2021
Apr 24 2021
Apr 21 2021
Apr 20 2021
Apr 16 2021
Looks promising so far! A few thoughts:
Apr 13 2021
Apr 11 2021
Apr 8 2021
I'm not sure I'm a fan of how internally the mirror_mesh function takes a normal input yet the node exposes a rotation. In my opinion rotations should only be used where a unit vector does not provide enough information to an operation, this is not the case here. I can get how Euler might be more friendly to people hand tweaking values it also adds an unnecessary step for people working with vector math who have to convert it to Euler only for it to be converted back internally. Maybe gathering more community feedback could be helpful here.
Apr 7 2021
Thank you soo much for everyone's feedback and continued work in the surrounding areas! Things have been difficult and demotivating recently but I would like to return to this patch after D10906 lands for BKE_volume_grid_shallow_transform. Thanks again.
Apr 3 2021
Apr 2 2021
Since there is some discussion about the naming I will settle with the following:
Apr 1 2021
Just chatted about this with Hans, Jacques and Pablo and there was a consensus that we should probably rename the Grid attribute to Density.
Would it be possible to generalize this to other attributes than position? I could see users wanting to smooth things like uv's and normals/direction vectors as well. I'm wondering if this might be a good place to do an attribute smooth/blur.
Mar 31 2021
Mar 30 2021
Mar 29 2021
Mar 27 2021
Mar 26 2021
Mar 25 2021
Mar 24 2021
I vote to keep it as lean as possible and focus on one arbitrary axis with bisection. I'm not sure how merging works in the mirror modifier but if it only merges vertices with the opposite axis then that should be part of the node as well rather than a separate node. Three of them can be chained together with some boiler plate to make the full modifier.
Mar 23 2021
Mar 22 2021
Mar 20 2021
This isn't quite right, since theoretically a set_group can have multiple transforms (though we aren't using that ability yet).
It actually doesn't look like there is a need to store the grids and transforms in a temporary vector anyway. Also, take a look at the way the point distribute node does this. The way it's structured (storing an array of vectors (one for each instance) makes it relatively easy to parallelize the distribution for every instance.
[...]
Storing an array of vectors for the position isn't essential for the initial version of this node, I'd be fine if you didn't include that. But scattering for every transform in the array is important.
- Updated with suggestions
It appears it got reverted somehow... Don't know how that happened.
Mar 19 2021
@Charlie Jolly (charlie) Those improvements would be very welcome, I see the minimap has already started. It just seems like this task is being designed in isolation from best practices of the existing organization tools. I would like to see some interesting results and insights come out of this prototype as well, it just seems the design needs to try to acknowledge where the other tools work and find out where it best fits in.
Mar 18 2021
How and where is this any more effective at organization than properly utilizing the already existing solutions to graph organization?
Mar 17 2021
- Rebase
Mar 16 2021
I still have cautions about this concept and how having different parts of a node graph on different pages might be not helpful. Blender currently is in the right direction IMO to provide useful, organized node functionality between splitting functionality into managable layers with the modifier stack, to node groups, to the upcoming attribute processor design.
Removes voxel values to the default value?
Leaving this since master has progressed far ahead of this patch and the exporter is moving to C++. This code had unfinished business as the subsurface extension is not implemented to replace the troublesome transmission vs. subsurface hack and file paths with spaces don't raise warnings about compatibility issues.
Mar 15 2021
These nodes will actually be incredibly important to geometry nodes as well once the attribute processor node and support for openvdb's sdfs come to blender. It would open up a whole new way of procedural modeling. I'm very glad to see this getting updates and am rather hopeful.
Mar 14 2021
- Rebase
Investigated the issue with instance transforms. This code previously just uses VDB's "indexToWorld" call in order to convert voxel space coordinates to world space coordinates, to do this vdb must be aware of the transform. To solve this I apply the transform of the instances to the distributed points, It appears that non-instances always have an identity matrix transform which is nice because I can just rely on the VDB's transforms for them. I think I got it mostly working with the one caveat that since instances don't contribute to the VDB's "grid.voxelSize()" and messes up the spacing a bit on grid mode. Chasing it down the rabbit hole it appears to be stored in a Vec3d in openvdb::ScaleMap when the grid is initiated and I don't know how or if it would be possible to reconstruct spacing info and under what scenario we should since the only indicator would be the identity matrix from the "non-instance" on gather instances, which is still more than possible with actual instances.
- Fixed instance transforms
Nice work!!! I like how the cone is able to handle varying base and top sizes which is far more useful than the existing add cone operator.
Mar 13 2021
(Edit: Upon further inspection of the mockup it seems the potential issue was already accounted for)
Mar 11 2021
Mar 10 2021
Mar 8 2021
Mar 7 2021
I'll get more feedback on this. The intention was to break point distribute up into "Point Distribute Surface" and "Point Distribute Volume" I originally went with this because it read and was grouped better when adding the nodes in the menu.
My initial test was to use it like the existing Point Distribute node but it needs the Points to Volume to work.
I am aware of this, it requires an explicit volume definition in order to function (VDB) as described in the design notes. It isn't working on external volumetrics at the moment.
Mar 5 2021
- Update use bke::geometry_set_gather_instances
I'm wondering what to do about the stability of points through time. The regular point distribute node tries to handle this to the best of it's ability but VDB's Point Scatter API does not handle this. With the grid distribution mode it should be rather stable for free (as long as the volume is using the "size" mode) and all you would have to do is hash the position to create an "id" attribute, the random distribution mode presents more of an issue.
Clang format
Made suggested changes
- Changed tooltip to use "the"
- Removed unused includes
- Made "PositionsVDBWrapper" private members consistent with style guide (couldn't get references to work without bugs yet)
- Replaced "typedef" with "using"
- Fixed caught typos
- Removed unwanted error when no volume component is found to avoid noise
- Replaced random "get_input" with "extract_input" (copy and paste error)
- Improved error messages based on suggestions
- Used "TIP_()" macro for translation of error messages
- Fixed double copy
- Using arcanist
Mar 4 2021
Attempting to move to arc now.
Since I wasn't the clearest (probably even in my own mind) I was suggesting that since the different types of curve objects seem to share that functionality that there could be a way to break apart the curve types into how they are edited and how they are skinned. With how different (layers?) of edit types could be stacked in the curve data while how they generate geometry could be moved entirely into modifier space. This is since I have seen quite a few people in their workflows doing things like converting text objects into curves in order to achieve things like a neon tube effect when really what they are after is a different method of skinning but have to give up their preferred way of editing. But now that I think more about it that does introduce problems as well so this was probably just a false bit of connecting dots on my end.
However it does make sense that 2D curves should be their own "type" as well as they offer both changes in skinning as well as editing.