porting adaptive spacing to head branch (from GSoC 2010) #50939

Closed
opened 2017-03-14 02:30:27 +01:00 by Tom Musgrove · 22 comments
Member

This is porting of a completed feature (adaptive spacing) from GSoC 2010, that accidentally got dropped during the merge.

It is working now but slow on larger meshes (suspect I introduced a bug during porting) so not yet ready for review, but adequate for some user testing.

adaptive_spacing_works_but_slow.diff

Original work by Jason Wilkins during GSoC 2010

This is porting of a completed feature (adaptive spacing) from GSoC 2010, that accidentally got dropped during the merge. It is working now but slow on larger meshes (suspect I introduced a bug during porting) so not yet ready for review, but adequate for some user testing. [adaptive_spacing_works_but_slow.diff](https://archive.blender.org/developer/F508760/adaptive_spacing_works_but_slow.diff) Original work by Jason Wilkins during GSoC 2010
Tom Musgrove self-assigned this 2017-03-14 02:30:27 +01:00
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @TomMusgrove

Added subscriber: @TomMusgrove
Member

Added subscriber: @Blendify

Added subscriber: @Blendify
Member

Added subscriber: @JasonWilkins

Added subscriber: @JasonWilkins

Added subscriber: @ErickNyanduKabongo

Added subscriber: @ErickNyanduKabongo

Hi,
@TomMusgrove What adaptive spacing is for?

Hi, @TomMusgrove What adaptive spacing is for?
Author
Member

Hi Eric,

Adaptive spacing results in even daub spacing even though the geometry curves dramatically away from the viewport.

please see the two following images, the first shows two crease brush strokes done from the viewport, one without adaptive spacing (left) the other with (right)

blender_crease_stroke.png

After you rotate the view, you can see that there is uneven overlap with the stroke without adaptive spacing since the pixel space distance is drastically different than the on surface distance to the the geometry curvature. The adaptive spacing maintains a uniform daub distance even though the angle changes dramatically.

crease_adaptive_comparison_result.png

Hi Eric, Adaptive spacing results in even daub spacing even though the geometry curves dramatically away from the viewport. please see the two following images, the first shows two crease brush strokes done from the viewport, one without adaptive spacing (left) the other with (right) ![blender_crease_stroke.png](https://archive.blender.org/developer/F508846/blender_crease_stroke.png) After you rotate the view, you can see that there is uneven overlap with the stroke without adaptive spacing since the pixel space distance is drastically different than the on surface distance to the the geometry curvature. The adaptive spacing maintains a uniform daub distance even though the angle changes dramatically. ![crease_adaptive_comparison_result.png](https://archive.blender.org/developer/F508844/crease_adaptive_comparison_result.png)
Author
Member

adaptive_spacing_and_sampling_range.diff

new version of patch - this includes the 'sampling range' for planes. Will split into two patches soon. Sampling range allows the radius for determining the area plane to be smaller/larger than the radius used for sculpting the geometry - this allows the user to more precisely determine which faces they want to use to determine the plane when using a locked plane, or make the brush follow the surface more/less closely when using an unlocked plane.

[adaptive_spacing_and_sampling_range.diff](https://archive.blender.org/developer/F509859/adaptive_spacing_and_sampling_range.diff) new version of patch - this includes the 'sampling range' for planes. Will split into two patches soon. Sampling range allows the radius for determining the area plane to be smaller/larger than the radius used for sculpting the geometry - this allows the user to more precisely determine which faces they want to use to determine the plane when using a locked plane, or make the brush follow the surface more/less closely when using an unlocked plane.
Author
Member

Added versioning so that sampling_range for area_normal is added to brushes. adaptive_spacing_and_sculpt_sample_range_needs_jason_feedback.diff

Added versioning so that sampling_range for area_normal is added to brushes. [adaptive_spacing_and_sculpt_sample_range_needs_jason_feedback.diff](https://archive.blender.org/developer/F510069/adaptive_spacing_and_sculpt_sample_range_needs_jason_feedback.diff)
Author
Member

Found the bug(s) wasn't calculating adaptive spacing so was always doing 1% doh! and then I was using the view_normal instead of true_view_normal. All seems to be working right now.

adaptive_space_fixed_and_plane_sampling_range.diff

Found the bug(s) wasn't calculating adaptive spacing so was always doing 1% doh! and then I was using the view_normal instead of true_view_normal. All seems to be working right now. [adaptive_space_fixed_and_plane_sampling_range.diff](https://archive.blender.org/developer/F529238/adaptive_space_fixed_and_plane_sampling_range.diff)
Author
Member

Bug fix, I was doing an clamping and scaling that was unneccessary resulting in any brush that wasn't close to 50px radius getting the wrong spacing, sometimes dramatically.

adaptive_spacing_w_plane_sampling_range_fix_brush_size_variance.diff

Bug fix, I was doing an clamping and scaling that was unneccessary resulting in any brush that wasn't close to 50px radius getting the wrong spacing, sometimes dramatically. [adaptive_spacing_w_plane_sampling_range_fix_brush_size_variance.diff](https://archive.blender.org/developer/F532480/adaptive_spacing_w_plane_sampling_range_fix_brush_size_variance.diff)
Author
Member

line and curve are both 'space' strokes, and thus should have the space options available.

adaptive_space_and_area_plane_April_2_2017_patch2.diff

line and curve are both 'space' strokes, and thus should have the space options available. [adaptive_space_and_area_plane_April_2_2017_patch2.diff](https://archive.blender.org/developer/F532612/adaptive_space_and_area_plane_April_2_2017_patch2.diff)

I hate to bike-shed my own feature, but I hate the name "adaptive spacing". It seems like this should be the default behavior and the old screen-space based spacing should be called "spacing *based on screen distance" and adaptive spacing should just be "spacing". If you have to call this anything it should be "spacing *based on object distance"

I hate to bike-shed my own feature, but I hate the name "adaptive spacing". It seems like this should be the default behavior and the old screen-space based spacing should be called "spacing *based on screen distance" and adaptive spacing should just be "spacing". If you have to call this anything it should be "spacing *based on object distance"
Author
Member

I agree that it should be the default behaviour, eventually I'll make the old behaviour the option (screen spacing). Not quite ready to do that yet because I don't think it always gives better results.

I agree that it should be the default behaviour, eventually I'll make the old behaviour the option (screen spacing). Not quite ready to do that yet because I don't think it always gives better results.

I think it probably needs to over sample the surface (extra samples between where it will place dabs) and maybe even consider the derivative of the slope and do a proper quadrature to predict how much it should change spacing, instead of the simple change it does now (sorry if the implementation has been improved over my original simple one, I haven't had a chance to go over this patch)

I think it probably needs to over sample the surface (extra samples between where it will place dabs) and maybe even consider the derivative of the slope and do a proper quadrature to predict how much it should change spacing, instead of the simple change it does now (sorry if the implementation has been improved over my original simple one, I haven't had a chance to go over this patch)
Author
Member

Nope I haven't improved the design, and I agree that that would be a great improvement.

Nope I haven't improved the design, and I agree that that would be a great improvement.

Added subscriber: @dfelinto

Added subscriber: @dfelinto

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

Please create a proper patch in https://developer.blender.org/differential/diff/create/ using arcanist. Closing for now, but refer to this task when creating the patch so developers can read back the discussion.

Please create a proper patch in https://developer.blender.org/differential/diff/create/ using arcanist. Closing for now, but refer to this task when creating the patch so developers can read back the discussion.
Member

Added subscriber: @SebastianWitt

Added subscriber: @SebastianWitt
Member

I have just picked it up as a first starting project for GSoC and will create a patch if i have anything proper.
For now i have already hit a design snag.
The current problem is, changing the "screenspace" line spacing to "objectspace" line spacing.
As Jason already mentioned we need to sample the surface, measuring the distance traveled on the 3D object rather than measuring the distance moved by the mouse.
This poses quite a challenge in the aspect of performance because the surface needs to be sampled.

As long as we are not doing any fancy methods like evaluating the depth-framebuffer to calculate distance underneath the Strokeline i see two options:

  1. calculate the true distance by measuring the "crossline" over all faces underneath the stroke. (performance scales proportional to mesh complexity).
  2. sample the surface along the stroke with a reasonable amount of points (maybe taking normal into account) and calculate the distance between these points.

If any, which option is reasonable to realise this feature? In which direction should I investigate further?
Currently i think option 2. is reasonable. A small sample size would result in a similar effect like screenspace spacing and a bigger sample size results in more precise spacing.
For testing i tried it with the standard brush polling and got decent results when moving the mouse slowly (slow => more sample points on a surface)

Maybe there is already a system to get the 3D projected shape of a stroke which i am missing? (Grease pencil seems to sample the surface like option 2 but i have not checked the code thoroughly)

Edit:
I did some more research on the way GP handles the "draw on surface". It turns out that it uses view3d_opengl_read_Z_pixels to sample the depth per point created. So it is

doing any fancy methods like evaluating the depth-framebuffer

I was not expecting that but may be an option as well. The question then arises what to do if the sculpt object gets obscured by other objects.

I have just picked it up as a first starting project for GSoC and will create a patch if i have anything proper. For now i have already hit a design snag. The current problem is, changing the "screenspace" line spacing to "objectspace" line spacing. As Jason already mentioned we need to sample the surface, measuring the distance traveled on the 3D object rather than measuring the distance moved by the mouse. This poses quite a challenge in the aspect of performance because the surface needs to be sampled. As long as we are not doing any fancy methods like evaluating the depth-framebuffer to calculate distance underneath the Strokeline i see two options: 1. calculate the true distance by measuring the "crossline" over all faces underneath the stroke. (performance scales proportional to mesh complexity). 2. sample the surface along the stroke with a reasonable amount of points (maybe taking normal into account) and calculate the distance between these points. If any, which option is reasonable to realise this feature? In which direction should I investigate further? Currently i think option 2. is reasonable. A small sample size would result in a similar effect like screenspace spacing and a bigger sample size results in more precise spacing. For testing i tried it with the standard brush polling and got decent results when moving the mouse slowly (slow => more sample points on a surface) Maybe there is already a system to get the 3D projected shape of a stroke which i am missing? (Grease pencil seems to sample the surface like option 2 but i have not checked the code thoroughly) Edit: I did some more research on the way GP handles the "draw on surface". It turns out that it uses view3d_opengl_read_Z_pixels to sample the depth per point created. So it is > doing any fancy methods like evaluating the depth-framebuffer I was not expecting that but may be an option as well. The question then arises what to do if the sculpt object gets obscured by other objects.
Member

Added subscriber: @decoda

Added subscriber: @decoda
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#50939
No description provided.