Reworked logic in the few places that still called this. Deleted the "GLSL not supported" fallbacks.
Also removed some nearby checks for ARB_multitexture and OpenGL 1.1. Blender 2.77 removed checks like this, but game engine still has some.
Built-in shaders now use uniforms instead of legacy built-in matrices. So far I only hooked this up for new immediate mode.
We use the same matrix naming convention as OpenGL, but without the gl_ prefix, e.g. gl_ModelView becomes ModelView.
Right now it can skip the new matrix stack and use the legacy built-in matrices app-side. This will help us transition gradually from glMatrix functions to gpuMatrix functions.
Still some work to do in gpuBindMatrices. See TODO comments in gpu_matrix.c for specifics.
@zeauro reported this issue:
texture2DRect needs the ARB_texture_rectangle extension.
But isn't that an OpenGL 2.1 feature and should be part of GLSL 1.2+?
This should fix it, and future shaders should do something similar.
We were checking for number of tasks from given pool already active, and
then atomically increasing it if allowed - this is not correct, number
could be increased by another thread between check and atomic op!
Atomic primitives are nice, but you must be very careful with *how* you
use them... Now we atomically increase counter, check result, and if we
end up over max value, abort and decrease counter again.
Spotted by Sergey, thanks!
Got rid of GLU and some matrix manipulation. Everything is shader driven now, drawn with point sprites.
Still plenty to do in this file...
Part of T49042 and T49043
Simple convert of drawing emboss lines to new immediate mode.
Part of T49043
Reviewers: merwin
Reviewed By: merwin
Subscribers: dfelinto
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2271
Made function categories more clear & added more notes about how to use this API.
immEndVertex is no longer part of the public API.
Minor cleanup & organizing of recent additions.
I change UI_draw_roundbox_gl_mode to use immediate API.
The rest of the change is the call to the function.
I also make some change in UI_ThemeColor4(int colorid) for eg to make convenience to use.
I would really like to know if it's the good way to do, if yes I will make all the change in the node_daw.c after, else say me what's wrong and how to deal with color else.
Reviewers: merwin, dfelinto, Severin
Reviewed By: merwin
Subscribers: fablefox, Severin
Tags: #bf_blender_2.8, #opengl_gfx
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2274
Since the collision modifier cannot be disabled, it causes a constant
hit on the viewport animation playback FPS. Most of this overhead can
be automatically removed in the case when the collider is static.
The updates are only skipped when the collider was stationary during
the preceding update as well, so the state is stored in a field.
Knowing that the collider is static can also be used to disable similar
BVH updates for substeps in the actual cloth simulation code.
Differential Revision: https://developer.blender.org/D2277
@dfelinto reported crash when setting grid subdivisions too low.
Code was setting color twice and Gawain was catching this. Fix is to only set regular grid color when we have regular grid lines to draw. Then emphasized grid lines are free to set their own color further down.
Previously if the rendering is much faster than saving (for example,
when transcoding stuff via VSE) it was possible to have 100s of frames
in memory.
This isn't ideal because of limited amount of RAM, so need to have
some sort of limit. This is exactly what is implemented in this commit.
By the design of task scheduler it was possible that tasks from somewhere
in the middle of scheduled list will be handled first.
For example, one thread might be iterating over the scheduled list and
ignore tasks because there is other thread is working on task from the
same pool. However, if that other thread finishes task before iteration
is over current thread will pick up task from somewhere in in the middle
of the list.
This isn't a problem in general case, but for movie rendering we do need
to have strict order of frames.
This commit lands the core backend of the Custom Manipulators project onto the blender2.8 branch. It is a generic backend for managinig interactive on-screen controls that can be integrated into any 2D or 3D edito. It's also already integrated into the window-manager and editor code where needed.
NOTE: The changes here should not be visible for users at all. It's really just a back-end patch. Neither does this include any RNA or Python integration.
Of course, there's still lots of work ahead for custom manipulators, but this is a big milestone. WIP code that actually uses this backend can be found in the 'custom-manipulators' branch (previously called 'wiggly-widgets').
The work here isn't completely my own, all the initial work was done by @Antony Riakiotakis (psy-fi) and - although it has changed a lot since them - it's still the same in essence. He definitely deserves a big credit! Some changes in this patch were also done by @Campbell Barton (campbellbarton). Thank you guys!
Merge accepted by @brecht and @merwin.
Patch: https://developer.blender.org/D2232
Code documentation: https://wiki.blender.org/index.php/Dev:2.8/Source/Custom_Manipulator
Main task: https://developer.blender.org/T47343
More info: https://code.blender.org/2015/09/the-custom-manipulator-project-widget-project/
This allows appending of an entire scene from another blend file into
this one, even when that blend file contains proxified armatures.
Since the proxified object needs to be linked (not local), this will
only work when the "Localize all" checkbox is disabled. The appended
proxy object should also not be referenced from anything in a library
(for example in a constraint). Referencing it from the appended data
should be fine.
Fixes T49495.
Pretty much same reason as for the 'from' pointer of shapekeys - runtime
data creating loops and 'ghost' dependencies between datablocks.
We need to handle them in cases like remapping, but whall not take them
into account to check dependencies between datablocks... :/
Want to avoid updating code we no longer use anyway.
Comments for areas to investigate or deadlines for deletion.
also some minor bool cleanup
Part of T49165
We can't prevent users from using this branch, so I'd say it's reasonable to be a bit careful about what we store to files. In this concrete case we were storing a bit-flag for temporary use (only during early viewport transition) in a bit-field that's saved in files. Doing so would mean we either can't reuse this bit later or we risk breaking files (admittedly, likely in a pretty minor way). Moved the bit-flag to a new bit-field which can be removed later.
