| Age | Commit message (Collapse) | Author |
|---|
|
GPU_material_bind_uniforms() to GPU_material_bind(). This way, material specific uniforms don't need to be resent when sending object specific uniforms. This saves uniform update calls in the BGE where one material is bound and multiple objects can be drawn. This doesn't offer much in the way of performance, but it cleans up our OpenGL usage a bit. One test scene went from 8k OpenGL calls to 4k with just this one change.
|
|
|
|
functions.
|
|
|
|
|
|
brushes, due to issues with color coded drawing or slow/buggy reading from such
a buffer on some systems.
In case multisample is enabled now, it uses an offscreen buffer for such drawing,
which is not multisampled and so should not cause issues. This does mean there is
some extra GPU memory usage when multisample is enabled, and we could optimize
triple buffer to work together here somehow to share buffers, but it's better than
having selection not working.
|
|
|
|
|
|
also minor code cleanup.
|
|
|
|
for bmesh dissolve.
|
|
* Rename functions and move to own header.
* Add wrapper functions for glLight.
* Auto detect if we can use faster code for solid lighting.
* Various fixes for textured draw mode.
|
|
|
|
always used in that context so we can at least avoid reverting it twice
:p.
|
|
datablock has
a Use Alpha option again. This makes the case where you enabled Premultiply on the
image and disabled Use Alpha on the texture work again.
That's mostly useful when you have a straight alpha image file which has no useful
RGB colors in zero alpha regions (e.g. renders). Then sometimes you don't want to
use the alpha for the texture stack mixing, but you still want to multiply it into
the RGB channels to avoid a blocky transition into zero alpha regions.
This also removes the version patch that copied image datablocks because it's not
reliable and might be causing bug #34434. This does mean we are no longer backwards
compatible for cases where two different texture datablocks with Use Alpha enabled
and disabled where using the same image.
|
|
code is still unused, but the intention is to use this to solve the double sided
lighting problem on NVidia, and to make the materials work on OpenGL ES 2.0
eventually.
The code works and matches the fixed function lighting pretty much exactly, but
still needs optimizations. The actual integration in object draw will be
committed later when more fixing & testing, there's lots of different combinations
and unclear OpenGL state here.
|
|
materials, the typical glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); blend
function does not give correct destination alpha.
|
|
|
|
Issue was caused by alpha pipeline cleanup: apparently depending on
use_alpha flag different channels for spec/alpha would be used.
Made it so talpha is computed from Image->ignore_alpha instead of
always considering to be TRUTH.
This is not so much trivial to understand what's going on here, but
it's not new issue. Anyway, if someone have got ideas how to improve
feedback here -- ideas are welcome! For now only regression is fixed.
|
|
|
|
it's working as expected out of the box. I hope nothing breaks.
|
|
|
|
Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
|
|
Moved the GPU function gpu_bmesh_face_visible() to BKE_paint and
inverted the test to match equivalent tests for other mesh types:
paint_is_bmesh_face_hidden().
Changed BKE_pbvh_bmesh_node_save_orig() to not save hidden faces into
the triangle array.
Modified the non-use-original branch of pbvh_bmesh_node_raycast() to
skip hidden faces.
Fixes bug #33914:
projects.blender.org/tracker/index.php?func=detail&aid=33914&group_id=9&atid=498
|
|
conversion).
|
|
not work in the viewport nor do they work for Variance shadow maps.
|
|
This assumptions are now made:
- Internally float buffers are always linear alpha-premul colors
- Readers should worry about delivering float buffers with that
assumptions.
- There's an input image setting to say whether it's stored with
straight/premul alpha on the disk.
- Byte buffers are now assumed have straight alpha, readers should
deliver straight alpha.
Some implementation details:
- Removed scene's color unpremultiply setting, which was very
much confusing and was wrong for default settings.
Now all renderers assumes to deliver premultiplied alpha.
- IMB_buffer_byte_from_float will now linearize alpha when
converting from buffer.
- Sequencer's effects were changed to assume bytes have got
straight alpha. Most of effects will work with bytes still,
however for glow it was more tricky to avoid data loss, so
there's a commented out glow implementation which converts
byte buffer to floats first, operates on floats and returns
bytes back. It's slower and not sure if it should actually
be used -- who're using glow on alpha anyway?
- Sequencer modifiers should also be working nice with straight
bytes now.
- GLSL preview will predivide float textures to make nice shading,
shading with byte textures worked nice (GLSL was assuming straight
alpha).
- Blender Internal will set alpha=1 to the whole sky. The same
happens in Cycles and there's no way to avoid this -- sky is
neither straight nor premul and doesn't fit color pipeline well.
- Straight alpha mode for render result was also eliminated.
- Conversion to correct alpha need to be done before linearizing
float buffer.
- TIFF will now load and save files with proper alpha mode setting
in file meta data header.
- Remove Use Alpha from texture mapping and replaced with image
datablock setting.
Behaves much more predictable and clear from code point of view
and solves possible regressions when non-premultiplied images were
used as textures with ignoring alpha channel.
|
|
This adds an override to the CDDM edge drawing function that switches
to GPU_Buffers drawing for PBVHes of type PBVH_BMESH.
Within the GPU_Buffers code, glPolygonMode() is used to draw lines
instead of faces.
|
|
The GPU interface for PBVH drawing gets a new pair of build/update
buffers functions for drawing BMFaces and BMVerts.
TODO: the diffuse color is hardcoded to 0.8 gray rather than using
material color.
TODO: only VBO drawing is implemented, no immediate mode.
|
|
|
|
"Divide" still differs too for division by zero - cannot find this yet...
|
|
Material Texture blend modes Screen, Overlay and Multiply didn't respect
the alpha for textures... an error I could trace back to 2004 even.
Obviously the fix should be done, but it might change the appearance of
renders somewhat. Will keep an eye open if this is worth ugly
version-patching.
Now: image textures with alpha, will only apply the blend modes
respecting the alpha values.
|
|
|
|
|
|
minification.
|
|
VBO's were using a material limit half the size of the rest of blender.
|
|
|
|
Also changed shebang to '#!/usr/bin/env python', this is more portable across unixes...
|
|
causing textures to be missing in textured draw mode. There is apparently a bug
in the ATI drivers, committed a workaround for that now.
http://www.opengl.org/wiki/Common_Mistakes#Automatic_mipmap_generation
|
|
|
|
it takes up less memory on some cards, still unclear why.
|
|
When FBO failed in a particular way it could cause the opengl draw buffer to be
set wrong, effectively disabling all opengl drawing. The FBO error was caused
by cycles GLSL materials with no nodes that would still use blender internal
materials, which caused issues with lamp shadow buffers FBO.
This also fixes a GLSL refresh issue when switching render engines.
|
|
engine.
|
|
OpenGL 1.4 feature that is stable, there's no reason not to use it. Also fixed
GPU mipmap generation not working in the game player.
|
|
on Nvidia cards," which was also reported by HG1.
|
|
This commit makes BKE_image_acquire_ibuf referencing result, which means once
some area requested for image buffer, it'll be guaranteed this buffer wouldn't
be freed by image signal.
To de-reference buffer BKE_image_release_ibuf should now always be used.
To make referencing working correct we can not rely on result of
image_get_ibuf_threadsafe called outside from thread lock. This is so because
we need to guarantee getting image buffer from list of loaded buffers and it's
referencing happens atomic. Without lock here it is possible that between call
of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would
be called. Image signal handling too is blocking now to prevent such a
situation.
Threads are locking by spinlock, which are faster than mutexes. There were some
slowdown reports in the past about render slowdown when using OSX on Xeon CPU.
It shouldn't happen with spin locks, but more tests on different hardware would
be really welcome. So far can not see speed regressions on own computers.
This commit also removes BKE_image_get_ibuf, because it was not so intuitive
when get_ibuf and acquire_ibuf should be used.
Thanks to Ton and Brecht for discussion/review :)
|
|
add a check for duplicates in BlenderLib()m, if 0'd now.
|
|
* Fix GLSL memory leak in the (vector) math node.
* Fix GLSL math node pow behavior for negative values, same as was done for C.
|
|
Roughness, Anisotropy and Rotation. Also a fix for automatic tangents and
OSL attribute handling.
Meaning of new sockets explained in the documentation:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Anisotropic
|
|
|
