On its own, the main functionality of the Radial Tiling node
is the ability to divide a 2D Cartesian coordinate system into
as many radial segments as specified by the "Segments" input.
Each segment has its own affinely transformed coordinate system,
provided through the "Segment Coordinates" output, which can be
used to tile textures in a radially symmetric manner.
Additionally, a unique index is provided for every segment through
the "Segment ID" output, the width of each segment at Y-coordinate
of the "Segment Coordinates" output without normalization = 0 is
provided through the "Segment Width" output and the rotation value
of the affine transformation of the coordinate system of each segment
is provided through the "Segment Rotation" output.
The roundness of the coordinate lines of the "Segment Coordinates"
output can be controlled through the "Roundness" inputs.
This can be used to make the coordinate systems of the segments
a mix of Cartesian and polar coordinates.
Lastly, the lines of points of the "Segment Coordinates" output with
constant Y-coordinates have the shape of polygon with rounded corners,
which can be used to procedurally create rounded polygons.
Pull Request: https://projects.blender.org/blender/blender/pulls/127711
These are causing quite a big difference in existing files, which is not
easy to address in versioning. Since the goal of removing this was to
simplify things for us and that's not the case, just revert this change.
This reverts commit ab21755aaf.
Ref #139923
Pull Request: https://projects.blender.org/blender/blender/pulls/146336
This mode is based on the same athmospheric model as the previous one, but now
also accounts for multiple scattering and reflections from the ground.
This increases the accuracy, especially at low elevations.
Also renames some options for consistency:
- The previous "Nishita" model is now "Single Scattering"
- "Dust" is now "Aerosols"
- Default altitude is now 100m.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/140480
"Use Nodes" was removed in the compositor to simplify the compositing
workflow. This introduced a slight inconsistency with the Shader Node
Editor.
This PR removes "Use Nodes" for object materials.
For Line Style, no changes are planned (not sure how to preserve
compatibility yet).
This simplifies the state of objects; either they have a material or
they don't.
Backward compatibility:
- If Use Nodes is turned Off, new nodes are added to the node tree to
simulate the same material:
- DNA: Only `use_nodes` is marked deprecated
- Python API:
- `material.use_nodes` is marked deprecated and will be removed in
6.0. Reading it always returns `True` and setting it has no effect.
- `material.diffuse_color`, `material.specular` etc.. Are not used by
EEVEE anymore but are kept because they are used by Workbench.
Forward compatibility:
Always enable 'Use Nodes' when writing blend files.
Known Issues:
Some UI tests are failing on macOS
Pull Request: https://projects.blender.org/blender/blender/pulls/141278
This adds a function that can turn an existing `bNodeTree` into an inlined one.
The new node tree has all node groups, repeat zones, closures and bundles
inlined. So it's just a flat tree that ideally can be consumed easily by render
engines. As part of the process, it also does constant folding.
The goal is to support more advanced features from geometry nodes (repeat zones,
etc.) in shader nodes which the evaluator is more limited because it has to be
able to run on the GPU. Creating an inlined `bNodeTree` is likely the most
direct way to get but may also be limiting in the future. Since this is a fairly
local change, it's likely still worth it to support these features in all render
engines without having to make their evaluators significantly more complex.
Some limitations apply here that do not apply in Geometry Nodes. For example,
the iterations count in a repeat zone has to be a constant after constant
folding.
There is also a `Test Inlining Shader Nodes` operator that creates the inlined
tree and creates a group node for it. This is just for testing purposes.
#145811 will make this functionality available to the Python API as well so that
external renderers can use it too.
This adds a boolean output for each of the menu items. The output is true, if
the passed in menu value is that item. This avoids the need to compare the
output value to the input values to get a boolean for whether a specific menu
item was passed in.
Support is added for Geometry Nodes as well as the Compositor. Usage/Value
inferencing has been updated as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/145712
* Add ACES SDR to HDR displays
* Add ACES reference gamut compression look.
* Name non-HDR AgX for HDR displays "AgX - SDR", consistent with ACES and
makes it more clear that this may not be the one you want for HDR. This
required updating test blend files.
* Mark all non-sRGB view transform colorspaces as inactive, so they don't
pollute the colorspaces list. The HDR ones were already inactive.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/145820
Certain packed images, like those loaded directly into memory with
`BKE_image_packfiles_from_mem`, would cause USD to process the images as
"in memory" rather than as "packed" because the API was not removing the
IMG_GEN_TILE flag.
Additionally, be sure to use the packed filepath whenever possible
rather than the name given to the Image datablock as this ensures the
correct file names are used inside the USD file and for the resulting
file on disk after export.
This also fixes 2 render tests which now match when compared to the
native renders.
Pull Request: https://projects.blender.org/blender/blender/pulls/145749
* Store scene linear to XYZ conversion matrix in each blend file, along
with the colorspace name. The matrix is the source of truth. The name
is currently only used for error logging about unknown color spaces.
* Add Working Space option in color management panel, to change the
working space for the entire blend file. Changing this will pop up
a dialog, with a default enabled option to convert all colors in
the blend file to the new working space. Note this is necessarily only
an approximation.
* Link and append automatically converts to the color space of the main
open blend file.
* There is builtin support for Rec.709, Rec.2020 and ACEScg working spaces,
in addition to the working space of custom OpenColorIO configs.
* Undo of working space for linked datablocks isn't quite correct when going
to a smaller gamut working space. This can be fixed by reloading the file
so the linked datablocks are reloaded.
Compatibility with blend files saved with a custom OpenColorIO config
is tricky, as we can not detect this.
* We assume that if the blend file has no information about the scene
linear color space, it is the default one from the active OCIO config.
And the same for any blend files linked or appended. This is effectively
the same behavior as before.
* Now that there is a warning when color spaces are missing, it is more
likely that a user will notice something is wrong and only save the
blend file with the correct config active.
* As no automatic working space conversion happens on file load, there is
an opportunity to correct things by changing the working space with
"Convert Colors" disabled. This can also be scripted for all blend files
in a project.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/145476
When shadow linking is enabled, `intersect_dedicated_light` is scheduled even
if the `PATH_RAY_SUBSURFACE` flag is set. This checks the flag and schedules
`intersect_subsurface` instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/145621
Replaces current basis function calculation which seems to be a direct
implementation of the recursive NURBS formulation. New implementation
avoids the need to check for zero divisions during iteration. Out of
bounds checks are also converted to asserts, assuming input provides
valid span index.
Performance wise this nets a 7+% performance improvement with the
average result being as fast or faster then the fastest execution
from previous implementation!
Pull Request: https://projects.blender.org/blender/blender/pulls/144457
Now that there are Rec.2100 PQ and HLG displays, the additional HDR option
for video export is redundant. Typically you would now select a HDR display
early on and do all your video editing with it enabled.
For saving a HDR video, the encoding panel will now show the name of the color
space, and warn when the video codec or color depth is incompatible.
Since this is now based on interop IDs for the dislpay color spaces, we can
map more of those to the appropriate CICP code. This works fine for Display P3,
in my tests it looks identical to sRGB except that the wide gamut colors are
preserved.
However Rec.1886 and Rec.2020 are problematic regarding the transfer function,
although the latter at least has the correct primaries now. So it should be
a net improvement and this could be looked at later if anyone wants.
---
Background:
* Rec.1886 and Rec.2020 display color spaces in Blender use gamma 2.4.
* BT.709 trc is almost the same as gamma 2.4, so seems like the correct choice.
* We already write sRGB with BT.709 trc, which seems wrong.
* Yet sRGB matches exactly between Blender display and QuickTime, while
Rec.1886 and Rec.2020 do not.
* Display P3 with BT.709 trc matches sRGB with BT.709 trc, just adding the wide
gamut colors. So that is what is used for now. Also using the sRGB trc the
file is not recognized by QuickTime.
There is apparently a well known "QuickTime gamma shift" issue, where the
interpretation of the BT.709 trc is different than other platforms. And you need
to do workarounds like writing gamma 2.4 metadata outside of CICP to get
things to display properly on macOS.
Not that QuickTime is necessarily the reference we should target, but just to
explain that changing the previous behavior would have consequences, and so
it this commit leaves that unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/145373
When instanced meshes were using FBX geometric transforms, the code
was not telling ufbx to create proper adjustment helper nodes due to
UFBX_GEOMETRY_TRANSFORM_HANDLING_MODIFY_GEOMETRY_NO_FALLBACK flag.
That flag was put in earlier, before import of armatures was solidified,
turns out using the proper flag (UFBX_GEOMETRY_TRANSFORM_HANDLING_MODIFY_GEOMETRY)
is not a problem anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/145527
This applies an OpenColorIO display, view and look transform on a color
in the scene_linear colorspace.
In general, OpenColorIO configurations do not contain a colorspace for
every view + display, especially if they are modern configs using the
display colorspace and shared view mechanisms. Nor do they include looks.
So the Convert Colorspace node is not sufficient.
Additionally, we would like to avoid making the colorspace list too long
in the default config, as we are adding many new views and transforms.
Exposure, gamma curves and white point functionality are not included
in this node, as there are native ways of doing that in the compositor.
These settings are marked non-editable in the Python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/145069
Refactor and revamp import and export of `UsdGeomNurbsCurves` prim
objects.
Fixes#130056, among other things.
Summary of changes and enhancements:
- Export:
- Write out `nurb_weight` attribute as the USD `pointWeights` primvar
- Properly write out cyclic NURBS curves data (* see notes)
- Import:
- Import using the new `Curves` datablock rather than the old `Curve`
- Properly read in cyclic NURBS curves data (* see notes)
- Tries harder to match incoming knot vector to standard `knots_mode`,
will use Custom otherwise
- Support import of all custom primvars and data attached to the prim
(for use with Geometry Nodes etc.) (* see notes)
Tests were added which check a variety of point count, order, knot_mode,
and cyclic combinations (generated through Geometry Nodes). A small
number of hand-crafted curves were used to test the Custom knots_mode
support on import. Additionally, the tests cover the case when there are
multiple curves defined for a single object.
Notes:
- Cyclic NURBS support is reliant on the current, under-spec'd, USD
documentation. Changes may be required in the future if/when the USD
spec is clarified: https://github.com/PixarAnimationStudios/OpenUSD/issues/3740
- Some Cyclic x knots_mode combinations are not correct and would
require more research to determine how to properly address.
- Custom attributes are not imported for Cyclic NURBS curves yet. Those
will require additional work to function correctly and are also
reliant on seeing how the USD spec changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/143970
In recent history there have been two issues leading to corrupt
rendering or crashes on the GPU in scenes with 300 or more unique
materials. #144713 and #141171.
To help detect these issues earlier on, this commit adds a new Cycles
render test that uses 400 unique materials.
Pull Request: https://projects.blender.org/blender/blender/pulls/145187
Implementation of the design task #142969.
This adds the following:
- Exact GPU interpolation of curves of all types.
- Radius attribute support.
- Cyclic curve support.
- Resolution attribute support.
- New Cylinder hair shape type.
What changed:
- EEVEE doesn't compute random normals for strand hairs anymore. These are considered legacy now.
- EEVEE now have an internal shadow bias to avoid self shadowing on hair.
- Workbench Curves Strip display option is no longer flat and has better shading.
- Legacy Hair particle system evaluates radius at control points before applying additional subdivision. This now matches Cycles.
- Color Attribute Node without a name do not fetch the active color attribute anymore. This now matches Cycles.
Notes:
- This is not 100% matching the CPU implementation for interpolation (see the epsilons in the tests).
- Legacy Hair Particle points is now stored in local space after interpolation.
The new cylinder shape allows for more correct hair shading in workbench and better intersection in EEVEE.
| | Strand | Strip | Cylinder |
| ---- | --- | --- | --- |
| Main |  |  | N/A |
| PR |  |  |  |
| | Strand | Strip | Cylinder |
| ---- | --- | --- | --- |
| Main |  | | N/A |
| PR | ||  |
Cyclic Curve, Mixed curve type, and proper radius support:
Test file for attribute lookup: [test_attribute_lookup.blend](/attachments/1d54dd06-379b-4480-a1c5-96adc1953f77)
Follow Up Tasks:
- Correct full tube segments orientation based on tangent and normal attributes
- Correct V resolution property per object
- More attribute type support (currently only color)
TODO:
- [x] Attribute Loading Changes
- [x] Generic Attributes
- [x] Length Attribute
- [x] Intercept Attribute
- [x] Original Coordinate Attribute
- [x] Cyclic Curves
- [x] Legacy Hair Particle conversion
- [x] Attribute Loading
- [x] Additional Subdivision
- [x] Move some function to generic headers (VertBuf, OffsetIndices)
- [x] Fix default UV/Color attribute assignment
Pull Request: https://projects.blender.org/blender/blender/pulls/143180
Blender grid rendering interprets voxel transforms in such a way that the voxel
values are located at the center of a voxel. This is inconsistent with OpenVDB
where the values are located at the lower corners for the purpose or sampling
and related algorithms.
While it is possible to offset grids when communicating with the OpenVDB
library, this is also error-prone and does not add any major advantage.
Every time a grid is passed to OpenVDB we currently have to take care to
transform by half a voxel to ensure correct sampling weights are used that match
the density displayed by the viewport rendering.
This patch changes volume grid generation, conversion, and rendering code so
that grid transforms match the corner-located values in OpenVDB.
- The volume primitive cube node aligns the grid transform with the location of
the first value, which is now also the same as min/max bounds input of the
node.
- Mesh<->Grid conversion does no longer require offsetting grid transform and
mesh vertices respectively by 0.5 voxels.
- Texture space for viewport rendering is offset by half a voxel, so that it
covers the same area as before and voxel centers remain at the same texture
space locations.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/138449
Add geometry file import nodes support to the for-each-path logic.
This will make `bpy.data.file_path_map()` report the input files for
OBJ, PLY, etc. import nodes (and any other node that has a string
property of subtype `PROP_FILEPATH`).
Currently this only supports static file paths, so where the file path
is set as the input socket's default value. When the path is
determined via any noodle, this is ignored and the default value is
reported anyway.
This is necessary for the new version of Blender Asset Tracer, which
in turn is needed to resolvestudio/flamenco#104423.
Pull Request: https://projects.blender.org/blender/blender/pulls/144874
Supports baking to object and tangent space.
Compatible with Cycles Vector Displacement node which has the
(tangent, normal, bitangent) convention.
The viewport situation is a bit confusing: seems that Eevee
does not handle vector displacement properly and rips all faces
apart. Cycles renders the displaced object correctly.
Not entirely happy with the UI, as displacement space does not
really belong to the Output, but so doesn't Low Resolution Mesh.
Perhaps the best would be to have a separate pass to revisit the
settings, and also make it more clear what the Low Resolution Mesh
actually does.
Pull Request: https://projects.blender.org/blender/blender/pulls/145014
PR https://projects.blender.org/blender/blender/pulls/144233.
Fix#142296 performance regression caused by merging UV positions
based on face area weights, replacing it with mean average weights
computation. The former method resulted in higher probability in making
subdivision cache invalid between frame updates and thus causing expensive
recreation of blender::bke::subdiv::OpenSubdiv_Evaluator object.
While this fix isn't directly answering a question why specific UV position
updates would cause this reevaluation of subdivision object, it fixes
the performance regression caused by #139595 PR.
Found while trying to import an instanced point-instancer with the
operator setting `support_scene_instancing=false`.
The point-instancer Prototype would be partially processed but not
completely since the option was disabled. This caused a discrepancy
during the final portion of import where the view layer was synced and
we attempted to query for an object that was not present.
Pull Request: https://projects.blender.org/blender/blender/pulls/144845
Almost all settings were duplicated between BakeData and RenderData.
The only missing field was the bake type, which is stored as a custom
property in Cycles.
This change:
- Removes unused bake_samples and bake_biasdist.
- Migrates settings like bake_margin to BakeData.
- Switches multires baker to use bake_margin.
- Introduces bake type in the BakeData, the same way how it was
defined in RenderData::bake_mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/144984
This change makes it so baking displacement to the high-resolution mesh
(Use Low Resolution Mesh option is OFF, displacement is calculated
between top multi-resolution level and subdivided viewport level mesh)
uses texture UVs and tangent space from the high-res mesh.
This matches intended use-case when object baked with such configuration
have subdivision surface applied to them bringing overall resolution to
the same level as the highest multi-resolution level.
The issue was simple to see when baking high-res displacement for an
object which uses "Keep Corners, Junctions" UV smoothing.
The unfortunate aspect is increased memory usage due to calculation of
the grid index and grid UV mapping, but it is not too bad (12 bytes per
loop, so is like 48Mb per million face). Feels like there is a way to
optimize it by utilizing knowledge that high-res mesh faces are created
in a specific order, but also feels it is not that important at this
moment.
Pull Request: https://projects.blender.org/blender/blender/pulls/144935
The main idea is to switch Bake from Multires from legacy DerivedMesh
to Subdiv. On the development side of things this change removes a lot
of code, also making it easier easier to rework CustomData and related
topics, without being pulled down by the DerivedMesh.
On the user level switch to Subdiv means:
- Much more closer handling of the multi-resolution data: the derived
mesh code was close, but not exactly the same when it comes to the
final look of mesh.
Other than less obvious cases (like old DerivedMesh approach doing
recursive subdivision instead of pushing subdivided vertices on the
limit surface) there are more obvious ones like difference in edge
creases, and non-supported vertex creases by the DerivedMesh.
- UV interpolation is done correctly now when baking to non-base level
(baking to multi-resolution level >= 1).
Previously in this case the old derived mesh interpolation was used
to interpolate face-varying data, which gives different results from
the OpenSubdiv interpolation.
- Ngon faces are properly supported now.
A possible remaining issue is the fact that getting normal from CCG
always uses smooth interpolation. Based on the code it always has been
the case, so while it is something to look into it might be considered
a separate topic to dig into.
It has ~1.2x speed-up on CPU and ~1.5x speed-up on GPU (tested on Metal
M2 Ultra).
Individual samples are noisier, but equal time renders are mostly
better.
Note that volume emission renders differently than before.
Pull Request: https://projects.blender.org/blender/blender/pulls/144451
The float buffer should be tagged with the standard untonemapped colorspace,
so that when we convert to PQ/HLG the tonemapping is preserved.
With this change:
* Using AgX highlights properly go to white.
* Using the ACES configs, we can convert EXRs to a HDR video, exactly
matching colors with the HDR video on https://dpel.aswf.io/solemates/.
Pull Request: https://projects.blender.org/blender/blender/pulls/144493
This test can't easily be updated because it relies on the old socket shape
design before #144119. Parts of it could be done from scratch again, but
most of this stuff is also tested by the new structure type inferencing test
in `bl_node_structure_type_inference.py`.
Pull Request: https://projects.blender.org/blender/blender/pulls/144185
This patch redesigns the File Output node to provide better UX and UI.
This is mainly achieved by allowing the user to create inputs by
dragging into an Extend socket and adjust existing inputs using the
familiar UI list design available in Blender. Additionally, various UI
changes were done:
- The Use Node Format option was renamed to Override Node Format for
clarity.
- Socket types are now fixed and do not change as new links are made,
allowing users to specify the exact output type and employ implicit
conversion if needed.
- The distinction between images and Multi-Layer EXR was made clearer.
- Final output paths are drawn in the UI to remove guess work.
- The Base Path was split into a Directory and a File Name.
- Panels were added to group options, include a panel for the node
format, items, and item formats.
Pull Request: https://projects.blender.org/blender/blender/pulls/141091
'exr multilayer passes' had an invalid input, so its output was updated
The rest of the tests had outdated output sockets after some 'Color'
sockets were converted into 'Vector' sockets
Pull Request: https://projects.blender.org/blender/blender/pulls/144004
Many nodes operate on all the instances that are passed into them. For example,
the Subdivision Surface node subdivides the mesh at the root but also instanced
meshes. This works well for most nodes, but there are a few nodes were the old
`modify_geometry_sets` function was not very well defined and it was tricky to
use correctly.
The fundamental problem was that the behavior is not obvious when a node creates
or modifies instances and how those are integrated with the already existing
instances.
This patch solves this with the following changes:
* Remove the old `GeometrySet::modify_geometry_sets` and related
`*_during_modify` methods.
* Add a new `blender::geometry::foreach_real_geometry` function that is similar
to the old `modify_geometry_sets` but has a more well-defined interface:
* It never passes instances into the callback. So existing instances can't be
modified with it.
* The callback is allowed to create new instances. This will automatically be
merged back with potentially already existing instances. The callback does
not have to worry about accidentally invalidating existing instances like
before.
* A few existing usages used `modify_geometry_sets` to actually modify existing
instances (usually just removing attributes). Those can't use the new
`foreach_real_geometry`, so they just get a custom simple recursive
implementation instead of using a generic function.
Pull Request: https://projects.blender.org/blender/blender/pulls/143898
This refactors the code for world to dome light to be shared between USD and
Hydra, and makes rotations work for Hydra the same way they do in USD.
One small behavior change is that missing image files now render black,
matching Cycles and EEVEE more closely.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/143035
This PR adds a new `fresnel_conductor_polarized` function, which calculates reflectance and phase shift (if requested) for both parallel and perpendicular polarized light. This is needed for applying thin film iridescence to conductors (see !141131).
For consistency, this PR also makes `fresnel_conductor` call `fresnel_conductor_polarized` instead of using a fast approximation of the Fresnel equations that is inaccurate at lower n and k values. This will change the output of some Metallic BSDF renders using Physical Conductor and prevent discrepancies when enabling thin film iridescence.
I didn't do any rigorous performance testing, but from timing the functions outside of Blender, `fresnel_conductor_polarized` is significantly slower than the approximation, between 1.5-3x depending on the compiler. This makes sense because it has three square roots and the approximation has none. In some informal tests with metallic_multiggx_physical.blend modified to have more spheres, the new renders took around 1-2% longer on both CPU and GPU.
There are some avoidable inefficiencies in this approach of just calling `fresnel_conductor_polarized`:
- one of the three square roots could be saved since `fresnel_conductor` never needs the phase shift and there are simplifications possible when only calculating the reflectance
- there are several unnecessary multiplications by 1.0 since `fresnel_conductor` uses relative IOR and `fresnel_conductor_polarized` doesn't, though those could get optimized out if inlined
Pull Request: https://projects.blender.org/blender/blender/pulls/143903
The current glare streaks threshold for highlights is too high so the
input is just a black image, and no effects are output.
The threshold was reduced from 2.0 to 0.2 to produce a visible change.
Pull Request: https://projects.blender.org/blender/blender/pulls/142320
`node_pixelate` sets the output pixel size to 1, meaning no
transformation occurs and it is essentially the same as a single value
input. This will add a new test that pixelates the image, and renames
the original test to better reflect that edge case
Coverage:
- Function: 62.50% -> 100%
- Line: 37.36% -> 100%
- Region: 45.83% -> 100%
- Branch: 20.00% -> 90.00%
Pull Request: https://projects.blender.org/blender/blender/pulls/142438
This PR adds more markers and re-tracks them correctly on the cube clip
The output should be a gradient color, which was tested with another
setup and should mask the clip if used in conjunction with the keying
node (this PR doesn't include that setup, just the keying screen fix).
Coverage remains the same.
Pull Request: https://projects.blender.org/blender/blender/pulls/142534
* Bezier (NURBS) import, supporting both Blender and external variants.
* Cleaner Bezier export, with better results importing in Rhino.
* Internal support for exporting the new Curves type.
* Tests covering a broad number of related cases.
The current NURBS exporter writes curve data directly, without accounting
for internal padding or how knots are generated from modes. This adjusts the
export behavior to omit data that does not influence the geometry of the
curve. The result is a simplified output that is easier to parse during import,
both for the importer and when importing to other platforms (Rhino).
Visual explanation to the adjustment can be found in #139174.
Importer is also adjusted to support variations in knot patterns. Extending
it to support the data generated by the exporter and by other platforms (Rhino).
This should resolve some issues in relation to #138732.
Integrated tests are added to broadly validate the common cases generated
by the exporter, including variations of different modes and NURBS order.
Regression tests are added to validate that the NURBS generated in Rhino
are imported as expected.
More details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/139174
