Terms get/set don't make much sense when casting values.
Name macros so the conversion is obvious,
use common prefix for easier completion.
- GET_INT_FROM_POINTER -> POINTER_AS_INT
- SET_INT_IN_POINTER -> POINTER_FROM_INT
- GET_UINT_FROM_POINTER -> POINTER_AS_UINT
- SET_UINT_IN_POINTER -> POINTER_FROM_UINT
This also include a small optimisation (remove of a double loop and half of
the memory allocation for hit points)
This should fix T55946 Crash using knife tool on mesh with large number of
vertices.
Tried with a 500K vert suzanne and it seems fine.
This is because depth test is set before drawing anything now. There is no
case where we want to draw without depth test that is not selection and
this case is not handle by v3d->zbuf anymore.
UI assume depth test is off by default. The DRWManager assume it's on.
This should fix T55623.
This translates the gl calls to the new GPU_ wrappers from D3501.
Given it's tedious and repetitive work, this patch does as much as it can with search + replace, the remainder of the gl calls will need to be manually dealt with on a case by case basis.
This fixes 13 of the 28 failing editors when building without opengl.
For the list of substitutions see D3502
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3502
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
- When returning the number of items in a collection use BLI_*_len()
- Keep _size() for size in bytes.
- Keep _count() for data structures that don't store length
(hint this isn't a simple getter).
See P611 to apply instead of manually resolving conflicts.
Both object level and camera datablock properties animation did not work with
copy on write enabled.
The root of the issue is going to the fact, that all interface elements are
referencing original datablock. For example, View3D has pointer to camera it's
using, and all areas which does access v3d->camera should in fact query for
the evaluated version of that camera, within the current context.
Annoying part of this change is that we now need to pass depsgraph in lots
of places. Which is rather annoying.
Alternative would be to cache evaluated camera in viewport itself, but then
it makes it annoying to keep things in sync.
Not sure if there is nicer solution here.
Reviewers: dfelinto, campbellbarton, mont29
Subscribers: dragoneex
Differential Revision: https://developer.blender.org/D3007
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.
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.
See GPU_matrix.h & gpu_matrix.c for the important changes. Other files are mostly just updated to use the latest API.
- remove unused functions, defines, enums, comments
- remove "3D" from function names
- init to Identity transform (otherwise empty stack)
- gpuMatrixReset lets outside code return to initial state
Part of T49450
Follow up to D2626 and 49fc9cff3b
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
Pretty sure source/blender is now finished, with all legacy matrix calls confined to gpu_matrix.c.
This was the easy part, but doing it first makes the next part much easier. TODO and XXX notes describe what is left.
glMatrixMode is still in place, since the new API does not share this concept of modes. Similar for glOrtho and glFrustum which I'll tackle very soon.
Part of T49450
