| Age | Commit message (Collapse) | Author |
|---|
|
The function definitions still reside in DerivedMesh.c. Once we're done
porting all the DerivedMesh use to Mesh, we'll move the still-relevant
functions to mesh_runtime.c. This move is now cumbersome due to shared
statically-declared utility functions in DerivedMesh.c
|
|
|
|
Strip unindented comment blocks - mainly headers to avoid conflicts.
|
|
Add mesh_get_eval_final & mesh_get_eval_deform
Note: these will eventually need to be renamed & moved into BKE.
|
|
|
|
Majority of the code is EOL, but still handy for debug purposes.
|
|
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
|
|
Folders removed entirely:
* //extern/recastnavigation
* //intern/decklink
* //intern/moto
* //source/blender/editors/space_logic
* //source/blenderplayer
* //source/gameengine
This includes DNA data and any reference to the BGE code in Blender itself.
We are bumping the subversion.
Pending tasks:
* Tile/clamp code in image editor draw code.
* Viewport drawing code (so much of this will go away because of BI removal
that we can wait until then to remove this.
|
|
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
|
|
This caused too many problems syncing object modes
with multiple objects/windows/workspaces, see: D3130 for details.
|
|
|
|
Also minor cleanup.
|
|
- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
|
|
|
|
Tentative fix, since I cannot reproduce thenissue for some reason here
on linux.
Core of the problem is pretty clear though, thanks to Germano Cavalcante
(@mano-wii): another thread could try to use looptris data after worker
one had allocated it, but before it had actually computed looptris.
So now, we use a temp 'wip' pointer to store looptris being computed
(since this is protected by a mutex, other threads will have to wait on
it, no possibility for them to double-compute the looptris here).
This should probably be backported to 2.79a if done.
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
|
|
concurrency.
Note: this commit seems to work as expected (also with transform
snapping etc.). However, it is rather unsafe - not enough for 2.79 at
least, unless we get much more testing on it. It also depends on three
previous ones.
Note that using a global lock here is far from ideal, we should rather
have a lock per DM, but that will do for now, whole DM thing is doomed
to oblivion anyway in 2.8.
Also, we may need a `DM_DIRTY_LOOPTRIS` dirty flag at some point. Looks
like we can survive without it for now though... Probably because cached
looptris are never copied accross DM's?
|
|
That one was doing exactly same thing as `dm->getLoopTriArray()`, no
point in having twice the same code here...
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
Patch by Alexander, with some refactoring by Brecht.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2709
|
|
- Derived-mesh drawing.
- All non UV members of TexFace structs.
MTexPoly is now redundant but keeping with a dummy member,
will check on complete removal later.
|
|
Generalize derived-mesh tangent calculation so
it can be used by Batch cache creation too.
|
|
|
|
We no longer need to rely on Derived mesh flag since the mesh is
properly flushed from the depsgraph
|
|
This includes a few fixes in the MBC_ api.
The idea here is for this to be the only interface the render engines
will deal with for the meshes.
If we need to expose special options for sculpting engine we refactor
this accordingly. But for now we are shaping this in a per-case base.
Note:
* We still need to hook up to the depsgraph to force clear/update of
batch_cache when mesh changes
(I'm waiting for Sergey Sharybin's depsgraph update for this though)
* Also ideally we could/should use BMesh directly instead of
DerivedMesh, but this will do for now.
Note 2:
In the end I renamed the `BKE_mesh_render` functions to `static
mesh_render`. We can re-expose them as BKE_* later once we need it.
Reviewers: merwin
Subscribers: fclem
Differential Revision: https://developer.blender.org/D2476
|
|
DerivedMesh owns this cache and cleans up as part of DM cleanup. DM has no idea what is stored in this cache. Loose coupling FTW
|
|
Was causing some invalid operations in OpenGL.
After more testing should be fine for 2.78.
|
|
Getting a new edit-derived-bmesh was always creating a deform-vert array, even when it wasn't needed.
Since this was called on redraw, in many cases it was doing it unnecessarily.
Now pass in a custom-data mask and only fill in deform-verts when needed.
Gives noticeable drawing speedup (~10-30% here).
|
|
A bit tricky, need to pass additional information about what the attribute
is and how to deal with it.
BI path stays unchanged, just to make things simplier for now.
Fixes T48555: Cycles GLSL- Incorrect Vertex Color results from Attribute node
|
|
Used ** arguments unnecessarily,
also replace BLI_linklist_apply with while loop.
|
|
Normal Map node support for GLSL mode and the internal render (multiple tangents support).
The Normal Map node is a useful node which is present in the Cycles render.
It makes it possible to use normal mapping without additional material node in a node tree.
This patch implements Normal Map node for GLSL mode and the internal render.
Previously only the active UV layer was used to calculate tangents.
|
|
Was called both, however this isn't mainly for uv's so just call 'flag'.
Also remove redundant NULL check.
|
|
Differential Revision: https://developer.blender.org/D1645
|
|
|
|
The generic tangent calculation relied on CDDM arrays which aren't available in edit-mode.
Add a tangent calculation callback, which has its own implementation for editmesh data.
|
|
|
|
Note that the collision modifier doesn't have any use for Loop indices,
so to avoid duplicating the loop array too,
MVertTri has been added which simply stores vertex indices (runtime only).
|
|
Notes:
* Code in rendering and in game engine will still convert
tangents to a tessface representation. Added code that
takes care of tangent layer only, might be removed
when BGE and rendering goes full mlooptri mode.
* Baking should work discovered some dead code while
I was working on the patch, also tangents are broken
when baking from multires (also in master), but those
are separate issues that can be fixed later.
This should fix T45491 as well
|
|
Looks like derivedmesh draw code always assumed a mesh is available.
Make sure that if we use a bmesh, a flag is used to control that.
|
|
|
|
|
|
Code was actually skipping setting color selection indices and previous
commit actually broke mask selection in texture painting.
All should work now.
|
|
|
|
This stores loop indices into the loop array giving easier acess
to data such as vertex-colors and UV's,
removing the need to store an MFace duplicate of custom-data.
This doesn't yet move all internal code from MFace to LoopTri just yet.
Only applies to:
- opengl drawing
- sculpting (pbvh)
- vertex/weight paint
Thanks to @psy-fi for review, fixes and improvements to drawing!
|
|
Get rid of legacy drawing, it's only used for selection,
in which case we can prepare a temporary color buffer and draw
at once. Code is not complete here because we still redundantly
set the draw color in the draw function and don't ommit hidden
faces automatically. Still it works 100% without immediate mode
now.
|
|
- use void instead of float for array arg (cast in the switch statement)
- remove unused args
- use const for poly-mapping and user_data args
|
|
This patch changes the way we draw meshes by introducing
indexed drawing. This makes it possible to easily
upload and rearrange faces ad lib according to any criteria.
Currently we use material sorting but textured sorting and
hiding will be added to optimize textured drawing and skip
per face testing.
It also adds support for vertex buffers for subsurf
modifiers (Except from GLSL drawing), making drawing of
subsurf much faster without need for bogus modifiers.
Tests show that we gain approximately 20-25% performance
by that for solid mode drawing with up to 50% gains for
material drawing. Textured drawing should also have a
small performance gain, but more substantial optimizations
are possible there.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1406
|
