| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
case a system does not support drawing to many framebuffers.
|
|
dyntopo just notify user that their system doesn't support it.
|
|
|
|
|
|
This is still not so correct, to make it work we really have to do a
blurring pass based on the real coc (currently we are just blending 3
levels of blur)
|
|
|
|
- spiral scheme is much more intuitive here. Also use float number for
spirals to avoid having samples on the same radial direction when sample
number is divisible by spiral number.
|
|
higher sample counts. Probably a blurring pass might be a good addition
here as well.
|
|
Previous behaviour would get occlusion at borders which could create
over occlusion at edges of the screen.
|
|
Naming here is slightly misleading. We have:
* Number of elements (objects) that can be picked
* Buffer size
* Number of integers in buffer.
Interestingly enough, bufsize in OpenGL (as far as I could find in
examples on the web) and in most of the code refers to the latter and
actual buffer size is only used whenever we do allocations on the heap.
Added an extra defines here to make things a bit clearer:
* MAXPICKELEMS refers to the number of objects that can be picked
* MAXPICKBUF refers to the number of integers in the selection buffer
Also made all buffers use MAXPICKBUF where some used MAXPICKBUF * 4.
That means that some parts of blender will use less space for selection
now. MAXPICKBUF is set to 10000 for 2500 object selection, which can be
changed at any time, but I think 10000 integers on the stack touches the
borders of uglyland anyway.
|
|
commit to remove from there will be done separately due to issues with
linking.
|
|
|
|
patch number D706 with changes:
- WITH_GPU_DEBUG just creates a debug context (and enables the debug messaging
system functions) but leaves the checks we had intact. Old patch
added the debug functionality only if we had the flag on to save some
performance.
Rationale here is that we might not want to recompile blender just to get
the extra information, and having users start blender with a -d flag to
get the extra information is also useful for bug reports. Those checks already
existed and most expensive ones are hidden behind a debug mode check
so performance should not be that bad.
- Did some cleanup of existing functionality:
When things go wrong blender side, just print the error,
don't check for GL errors first.
- Did not port changes needed for GLES to regular glew.h
- Got rid of duplicate or very similar new functionality.
Generally, code is more moving things around/cleanup and should work exactly
as before apart from the debug context, so it's safe to add even now.
It also provides a nice substitute function for glu error descriptions
|
|
Potential crash reading freestyle modifiers from future blend-files
|
|
set.
|
|
|
|
Basically, before drawing X-Rays, we now bind a second depth buffer.
After drawing XRays, we do an extra resolve pass where we overwrite the
non-XRay depth buffer in pixels where the depth is not maximum (which
means background pixel, since depth is cleared before drawing X-Ray
objects).
This ensures both scene and X-Rays keep their depth values and are ready
for compositing. Well, the odd effect due to depth discontinuities can be
expected, and X-Rays are a bit more expensive (extra buffer + resolve pass)
but at least X-Rays won't invalidate depth values anymore. Whee!
|
|
background.
For SSAO supporting this is no problem, for DOF we would ideally do
blurred alpha, but alpha channel in blurred buffers is occupied by coc
field, so use original color alpha instead. It's not entirely correct
but it's better than nothing.
|
|
The issue was caused by the recently added attribute, which is to be
added to the shader function even tho it's not supported.
|
|
This reverts commit ebd4a6e0dd3bdd511f3857dc9192df848f388200.
Trailing '}' is added in C, also we add some extra code as needed.
|
|
|
|
This commit introduces a few ready made effects for the 3D viewport
and OpenGL rendering.
Included effects are Depth of Field, accessible from camera view
and screen space ambient occlusion. Those effects can be turned on and
tweaked from the shading panel in the 3D viewport.
Off screen rendering will use the settings of the current camera.
WIP documentation can be found here:
http://wiki.blender.org/index.php/User:Psy-Fi/Framebuffer_Post-processing
|
|
|
|
|
|
|
|
Before this was hardcoded to 32, which I think was incorrect because
this is used to store a customdata layer name.
Reviewers: psy-fi, campbellbarton, sergey
Reviewed By: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D1040
|
|
So make it so comparison doesn't imply type-cast.
|
|
Issue here is that remote connection will use OpenGL 1.1.
There was a call here that would free VBOs always without a check,
however the VBO free function pointer is NULL on such contexts causing a
crash.
This must have been causing some of the crashes with old contexts. While
I think supporting those systems is not such a good idea in general,
they can have a few more moments of support I guess.
Things might be better now for systems using OGL 1.1 though there are
still things that could be done better here - for instance going to
dyntopo can crash immediately because we don't have a fallback
implementation there. It might be worth reimplementing sculpting with
vertex arrays for the legacy case too, but I guess if we move on to
OpenGL 2.1 soon this is a bit of a wasted effort.
|
|
Make it so by checking operand sign.
|
|
|
|
bounds instead of window bounds). Fixes remaining part of T43346
|
|
note, win32 casts still casts from double.
|
|
internal.
Similar to fix for T42074 we need to multiply with energy -after-
texture application.
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
In all but one call the value 0 (aka GPU_NONE) was passed in. Clearer
to just default to GPU_NONE and change the one caller that sets a real
type to do it explicitly.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Used this in GPU module to clarify what some "ints" really are.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
