Low-degree semi-structured splines for interactive modeling #91180
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
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
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#91180
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Low-degree semi-structured splines (LDssS) is a Blender add-on that converts quad-dominant meshes into B-spline patches.
This enables artists to edit spline surfaces in real-time via the existing polyhedral modeling capabilities of Blender.
Blender currently provides no convenient spline creation, modeling, or reshaping tool. Splines are a standard representation in the CAD industry.
LDssS, therefore, provides a bridge between Blender modeling and spline-based industrial design.
LDssS yields
Please visit the [documentation ]] and [ https:*github.com/UF-CISE-Surflab/blender-polyhedral-splines | source code for more details.
blender-semi-structure-spline.zip
Added subscriber: @m043010016
Added subscribers: @Funnybob, @DanielBystedt, @howardt
Thanks for this contribution, some questions regarding this functionality:
Some comments on this feature:
In it's current form this seems like a way to explore this method as an alternative to subdivision surfaces, however for this to be something that would be included in Blender, I think we would want this to be a modifier.
CC'ing @howardt, @DanielBystedt and @Funnybob for user feedback.
Speaking from an artists point of view: I have a hard time seeing the usefulness of the addon when doing actual modeling work. Therefore I am sceptical if it is worth the time to put a developer into making this a modifier. I would much rather that developers time would be put into tackling features that could be useful for a larger group of blender users (such as the UV improvements ;-) ). There are very few 3d artists that I know of that is using NURBS surfaces in their modeling workflow. The exception would be 3d hard surface modelers that use the 3d application "Moi 3D". The biggest selling point of that application is strong use of parametric modeling and boolean use.
A hypothetical usecase would be if I need to import a model into an 3d application that only accepts nurbs surfaces and not polygons. Then I could convert a mesh to nurbs surfaces before exporting.
That could be useful if you need to imply poly objects into CAD but usually it's the opposite. Now, doing a demo on a monkey is one thing, doing it on a highly complex surface with holes in it, that's another game. I would need to see a demo on a geo that has irregular poly distribution. I used NURBS since 1995. They are impossible to texture as they don't have UVs. You have to deal with texture stretching, time surfaces, tangent continuity and many other issues that we don't have with polys anymore. NURBS have their advantages, like doing fillets, but nothing I can't deal with in polys. NURBS also need tessellation otherwise they will look faceted. That is unless you use a renderer that fully support NURBS like Renderman that will do micropolygon tessellation.
@Funnybob this could be converted into a mesh modifier that handles UV coordinates and other custom data, so it may be worth considering this functionality without getting caught up in details about Blenders current NURBS support which is quite limited.
But what is the ultimate goal of this addon? Who is it for?
Added subscriber: @kursadk
This can provide better landing for the people coming from the CAD world, and make Blender more useful for them. I saw many people try to convert Nurbs objects to Blender with minimal curvature loss, maybe this add-on can be expanded in that direction.
Added subscriber: @zanqdo
The potencial usefulness of NURBS is beyond question when dealing with CAD models. It would be a dream to be able to load CAD objects in Blender.
However I agree that seing this in a Suzanne is not a good enough example of it's pottencial, specially since this is still based on Blender's ancient and limited NURBS patch so it is unclear how a real CAD surface would transfer to it.
Added subscriber: @pafurijaz-4
Added subscriber: @surfacionado
We need some help/input.
First what is now available thanks to your input:
^* Now our questions:
0. Is there a similar modifier that can be used for style and approach?
Currently, after making the surface, we call BKE_mesh_new_from_object to generate a fine mesh. That is not our favorite solution, see below.
1a Is rendering from the modifier to the OpenGl 4.x graphics pipeline an option?
1b Where do we find specific information for how Blender likes to link to the GPU? ( We are familiar with OpenGL 4x but reading the opensubdiv code is no fun)
1c Do we need to provide a legacy solution for ancient graphics cards?
2a. How does the built-in NURBS surface get rendered in Blender?
If it is an efficient and correct algorithm, we could just feed it our coefficients for legacy.
2b. Does Blender convert NURBS into mesh before rendering?
If so we may want to generate that mesh directly without NURBS intermediary.
2c. Can a modifier keep NURBS surfaces (not converting them into mesh)?
IGES (.igs) output format so that Blender polyhedral spline designs
can be directly exported to CAD packages?
Added subscriber: @TimMann
@surfacionado
Hi, somehow the patches around extraordinary vertices are not generated. Also is there a reason why the generated Bspline patches don't have knots?
Yes. it'll be nice to have an .igs exporter to verify it in Autodesk Alias.
Removed subscriber: @Funnybob
Thank you Tim
Polyhedral spline patterns [intentionally] require sufficient separation between the irregularities (see Mesh Inspection and minuite 2:45 of the video at https://uf-cise-surflab.github.io/blender-polyhedral-splines-web/ and the bottom of the page).
Btw: we renamed semi-structured to polyhedral splines...
You have three choices to avoid holes in the original Suzanne mesh which has many "tight" configurations:
We will add the igs exporter (that, incidentally, we wrote to compare the high-end version of polyhedral splines with Autodesk surfaces ;-)
@surfacionado Great, look forward to the igs exporter.
I'd definitely implement your localized remeshing algorithm to make it more robust if I were you, especially when Subdiv Modeling in Alias already works for all cases.
I also compared the result of Subdiv Modeling and Polyhedral Splines and marked some details that might be improved in the future.
B. The amount of patches at extraodinary point by Polyhedral Splines is a bit disproportional(Suzzane's nose), maybe it can be improved.
C. Having three coefficients at the same location(Suzzane's eye) seems like a temporary work around, not a final solution.
D. It's hard to tell if these crease lines are caused by different rendering engines or if it's a continuity problem without an .iges from Polyhedral Splines.
Thank you so much, Tim.
We hope to provide an update addressing 'holes' and 'iges' mid-August.
for now just on B:
on the left (subd) each "patch" of Catmull-Clark subdivision consists of an INFINITE sequence of polynomial pieces. You likely show is the projection of the control net on the surface -- that projection has the same structure for polyhedral splines. What you show on the right are the outlines of FINITELY many polynomial pieces of the polyhedral spline.
Why would a designer care whether it is infinitely many pieces (subd) or finitely many (polyhedral spline)? (1) export to iges, (2) exact moment computation, (3) no singularities (except at polar points, where the surface is perfectly smooth), whereas subd viewed in terms of patches generates singularities at every extraordinary point, etc.
@surfacionado
B on the left(Subdiv) is not a projection of the control net. it's the outlines of the actual Rational B-spline Surfaces . On the left of the image below is subdiv suzzane exported to .iges then imported back to Alias with 600 B-spline patches in total, on the right is a selected B-spline patch at nose area with cv/coefficients turned on. It's not a simple Catmull-Clark algorithm with infinite/singularity issue.
As for the number of Bspline patches, that depends on your target users. Most modern graphic cards are capable of handling Catmull-Clark on low poly objects, unless there're a million low poly objs; subdivision on high poly objects are mainly used in final production deployment in studios equipped with high end cards. Polyhedral Splines as an alternative lightweight visualization modifier to Catmull-Clark may seem trivial to these artists and studios, however you do have a real case among CAD users given the fact that B-splines parametric properties are necessity to them. Besides, in comparison to CAD vendors flexing their muscles into the Mesh Modeling world with 3-4 years old Subdiv Modeling feature from Alias(or other major CAD vendors) that preserves the original mesh topology with minimal amount of Bspline patches, Surface Modeling in Blender is seriously underdeveloped. If you try to acquire these potential CAD users and go head-to-head on the same feature, keep in mind they'll probably be looking for something similar in Blender to toggle across platforms. The less the patches, the easier it is for them to manipulate. Or you can offer something different, such as add the high end version you mentioned earlier to your advantage.
Great to get feedback, Tim!
We agree that the boundaries of the polynomial pieces are shown in light blue in your example and the boundaries of the macro-patches in bold blue.
The Alias output for the once Blender-subd-refined input per original quad is 2 x2 x degree bi-7 patches = (256 Bezier coefficients) .
Polyhedral splines use 9, resp. 16 Bezier coefficients.
As you point out, a factor of 16 may not matter and degree bi-7 vs bi-3 is not big deal unless of course you want to compute normals or curvature or intersections or ...
Also Blender does not seem to support degree higher than bi-3 and we were hoping to use Blender, not rebuild it.
So pulling the Alias solution into Blender will presumably fail, whereas exporting polyhedral splines from Blender or pulling polyhedral splines back into Blender is possible.
That is with iges output, one can toggle across platforms.
Polyhedral splines allow you to design using many configurations not supported by Alias, such as polar configurations and T-junctions.
Note that T-splines can model T-junctions using refinement but cannot handle input T-junctions since T-splines require a global parameterization.
We are late with posting the "no holes" version 2 and iges output as well as a nice example. But I am hopeful version 2 will arrive this month.
To get the modifier into Blender will depend on the level of enthusiasm. Basically startup with the modifier is instant whereas now , with the add-on, you have to wait for Blender to allocate each piece.
I am testing this with 3.4 nightly and I see that the patches have normals continuity issues. Is this an expected situation?
Added subscriber: @HooglyBoogly
Hi! I think this is quite an interesting concept! I can get why surfaces wouldn't be useful for a lot of artists, but having something like a surface workflow in Blender would be great.
I notice the conversation tends to come back to the limitations of Blender's current surface system.
I'd like to point out this design task I made for surfaces recently: blender/blender#100127 (New surface data-block)
It would be great to get feedback from people with more experience with surfaces there.
I realize that would probably take the project in a different direction than you're proposing, but if you're interested, I would be happy to help with work on that task.
Hi Kursad,
Thank you for pointing this out :) We also noticed this issue.
We wonder if it is because we misuse any functions or if it is a rendering issue in Blender.
The .igs exporter feature has been pushed to main branch .
We didn't see the discontinuity when exporting the same splines as igs file and display in FreeCAD.
We appreciate any comments!
Added subscriber: @lichtwerk
This could be due to some of the refactors to mesh normals that have happened recently. It may be necessary to give the mesh custom normals based on the evaluated NURBS patch.
Added subscriber: @persun
@surfacionado
ohh that's what those light blue outlines are, beizier patches. Thanks for clearing that up.
Those Alias surfaces are bi-3 to bi-7, and they support T-junctions and Polar. It's unfortunate that Blender doesn't support bi-3+.
Will it be updated soon? I can help forward it to a friend to share it with his students and in-house CAD modelers and gather some input.
Added subscriber: @Hans-6
Thank you Tim.
It may surprise, but Alias (or T-splines) do NOT support T-junctions in the sense that a polyhedral modeler needs it. In Alias, you can generate T-junctions by partitioning a quad facet. But you cannot input a polyhedral mesh with T-junctions and expect to get a surface back. (You can input a mesh with T-junctions for polyhedral splines of this addon. ) T-splines need a globally consistent knot sequence and that is often not possible.
We would love to have a functioning support for Bezier patches in Blender.
But so far we have not heard from anyone who knows and wants to tackle the innards of the curved surface implementation in Blender.
We know that pixel-accurate rendering (ray casting in real time -- certainly as fast as GPU opensubdiv) is both simple and feasible using only shaders in the openGL pipeline, entirely on the graphics card, without penalty for the CPU.
@Hans-6 Goudey
It is easy to provide the normal direction of a Bezier patch of degree bi-3 -- where would these "custom normals" be added to fix the problem Blender rendering seems to be experiencing (and iges output of the same Bezier patches to another renderer does not)?
I meant Hans Goudey (HoogleyBoogley)
Removed subscriber: @Hans-6
The normals could be added when generating the Mesh from the surface data. That's currently in
mesh_nurbs_displist_to_meshin the C++ code. It probably won't be that efficient but it's on the performance improvement list anyway. This might actually be a bug that this is missing.Like I mentioned before in this task though, I really think that a new surface data-block could the workflow here significantly. It could be dynamically generated from meshes or edited directly, and could be changed procedurally with directly in geometry nodes.
Considering the interested from various developers, I feel like that's a reasonable direction to take this project.
Thank you Hans! I do not know how to ask github nicely to tell me where mesh_nurbs_displist_to_mesh occurs. Maybe one has to clone to search?
There is a routine evaluate_segment that implements forward differencingfor a polynomial of degree 3 (the 3 in rt3) in one variable (presumably after converting from the B-spline form to Bezier form?).
My guess is that this routine is used, in parallel along the other variable, to fill an array?
Likely (I searched in vein for the cross product) the evaluation points are then interpreted as micro-quad facets and any normals are computed for those?
If this is a correct interpretation of the code, there is an alternative: one can evaluate efficiently (re-using all intermediate coefficients as one does in forward differencing) using de Casteljau's algorithm.
This allows computing exact normals in parallel. I have some code if that is of interest.
@surfacionado
Here's a rough model I made that contains T0/T1/T 2/Polar3/Polar5/Polar6/Polar7/Polar8/3-gon/5-gon/6-gon/7-gon/8-gon and the resulting surfaces in Alias are fine.
Here's the .blend file and output .
data.zip
Follow this video to reproduce.
turorial.mp4
Perhaps you can install and import a nurbs python library such as Nurbs-Python to Blender to go around the built-in limitations, decrease the degree only for Blender visualization purposes while keeping higher degree surfaces, etc.
Thank you Tim! I appreciate the detail and demo!
Yes, Alias software can apply two Catmull-Clark smoothing steps to any mesh: that eliminates T0/T1/T 2/Polar3/Polar5/Polar6/Polar7/Polar8/3-gon/5-gon/6-gon/7-gon/8-gon by converting them to isolated n-valent vertices.
T-splines cannot model the eliminated configurations.
Alias then fits degree bi-7 patches, (not T-splines).
So the final count is x16 pieces x 64 Bezier coefficients per sector vs (if built right from the start no Catmull-Clark is needed, otherwise x4 pieces) of 16 Bezier coefficients (degree bi-3 ).
That comparison is cheating slightly since polyhedral splines sometimes use multiple patches and for n>5 also uses more pieces. On the other hand bi-7 is more expensive to render and use downstream than bi-3.
The higher degree polyhedral splines work well with Rhino, but our goal was to donate to the Blender community a CAD-compatible smooth surface construction that uses the existing Blender infrastructure. Unfortunately, this infrastructure has degree 3 hard coded (so we adjusted to that) and does not render correctly (that is not a bug but an incorrect algorithm for generating the normals) .
If we knew where to place it, we would use the GPU tessellation engine for rendering the bicubic splines, avoiding conversion on the CPU and in Blender source altogether. I think "subd" does this already?
Any progress on the issue of incorrect rendering of bi-3 splines in Blender?
It is my understanding that bi-3 is the only supported degree option, or has that changed?
We'd be happy to bypass the incorrect evaluation and send the surface control points directly to the GPU if we get some help in setting this up (this was done for subd).