Blender Git Loki

hack up simple subdivisions in

Currently it'll still use legacy subsurf code.

Fix solid mode viewport texture painting overtrying to upload textures

Prevent crashes with meshes without faces

Rather strange crash from OpenSubdiv side, will investigate
it later. For now let's just not crash from Blender side.

fix attempt for messed up bake data after linking objects

Fix crash when compute type from user prefs is not supported by OpenSubdiv

Fix accidental crashes when changing subdiv level

Issue was caused by freeing GLMesh from non-main thread.
Since this might invoke OpenGL calls, better to free the
mesh from main thread instead.

Expose OpenSubdiv compute type to user preferences

Pretty much straightforward change actually.

NOTE: Use with care! Opening userpref during animation
playback crashes Blender here. Should be some sort of
OpenGL context issue, will investigate it later.

Also committing file missing from previons commit.

copy rigidbody world when linking objects to scenes (if it exists)

Further refactor of OpenSubdiv C-APi

Now it's possible to create GL Mesh with different types
of controllers and it's OpenSubdiv API which would worry
about how to allocate the controller.

Currently not exposed to UI and still hardcoded to CUDA.x

can copy rb bakedata now with scene

Skip DM face initialization when GPU backend is possible to use

Currently only last SS modifier in the stack is capable of using
GPU for tessellation. If there are any modifiers on top of SS then
CPU is gonna to be used (even if the modifier is disabled).

There's still uite reasonable amount of overhead happening, but
that's task for further design changes. For now let's make all
the bits working and when it's clear how it all communicates
re-design drawObject, derivedmesh and probably other areas.

Initialize osd_index of vert when adding vertex to the map

Saves some time when doing evaluation or GL drawing.

Fix memory leak around source config

There are also some other leaks happening in OpenSubdiv,
for until fixes are merged to upstream consider using

https://github.com/Nazg-Gul/OpenSubdiv

Move towards GPU-side tessellation

Currently only lands all the basics which are needed to
support using GPU tessellator from the OpenSubdiv library.

CPU evaluation is disabled in purposes of testing GPU side,
which means bounding box is wrong, edges are not displayed,
textured mode is likely also broken since now.

Data structures layout and API is not final at all, it is
just a cleaned version from the patch which i had last week.
All the drawing should be moved outside from the CCGSubSurf
structure and become some more generic functions in bf_gpu.

Also currently tessellation is hardcoded to use CUDA backend,
would either become an user preference or some automatic mode
in the future.

Wouldn't recommend using this state in the production, it's
still just a basis for further development and doing some
tests.

Replaced the `validate_links` method by `build_operations`.

The `build_operations` will need to be complemented with all the build
steps for operations currently mixed in with the node/relations builder.

crash fix for loading data with halving applied only (and no fracture)

Added new node method 'build_operations' which will replace the current
'validate_link' for constructing the inner nodes from ID- and component
nodes.

Removed the unused "Color" enum.

This was part of old depsgraph algorithms, but is not used in the new
code so far. Can be added back easily if required, but preferably in a
more transparent way (color meaning is far from intuitive).

Clean up DepsNode flag fields.

The OperationDepsNode.flag field would shadow the DepsNode.flag field.
These flags are only used for eval tagging atm, so it's safe to move
these into the OperationDepsNode class.

If necessary, similar flags for "directly modified" etc. could be added
to ID nodes or components too, but they can and should be conceptually
separate and use a non-conflicting flag in the respective subclasses.

Moved relations from generic DepsNode base class into OperationDepsNode.

Rationale here is that only relations between operations matter for the
final evaluation. Keeping this specific makes it easier to avoid
implicit assumptions and confusing upcasts in the evaluation code.

Relations between "outer" nodes (ID nodes and components) will be
translated directly into relations of their inner operation nodes (this
will require fully built operations lists at the time relations are
constructed). Higher level relations may be used for debugging purposes,
but they are not required for evaluation and should be handled in a
separate structure.