| Age | Commit message (Collapse) | Author |
|---|
|
This commit contains all the remained parts needed for initial integration of
OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU
backends which works in the following way:
- When SubSurf modifier is the last in the modifiers stack then GPU pipeline
of OpenSubdiv is used, making viewport performance as fast as possible.
This also requires graphscard with GLSL 1.5 support. If this requirement is
not met, then no GPU pipeline is used at all.
- If SubSurf is not a last modifier or if DerivesMesh is being evaluated for
rendering then CPU limit evaluation API from OpenSubdiv is used. This only
replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG
structures exactly the same as they used to be for ages now.
This integration is fully covered with ifdef and not enabled by default
because there are several TODOs to be solved first:
- Face varying data interpolation is not really cleanly implemented for GPU
in OpenSubdiv 3.0. It is also not implemented for limit evaluation API.
This basically means we'll have really hard time supporting UVs.
- Limit evaluation only works with adaptivly subdivided meshes so far, which
basically means all the points of CCG are pushed to the limit. This gives
different result from old code.
- There are some serious optimizations possible on the topology refiner
creation, which would speed up initial OpenSubdiv mesh creation.
- There are some hardcoded asumptions in the GPU and DerivedMesh areas which
could be generalized.
That's something where Antony and Campbell can help, making it so the code
is structured in a way which is reusable by all planned viewport projects.
- There are also some workarounds in the dependency graph to make sure OpenGL
buffers are only freed from the main thread.
Those who'll be wanting to make experiments with this code should grab dev
branch (NOT master) from
https://github.com/Nazg-Gul/OpenSubdiv/tree/dev
There are some patches applied in there which we're working on on getting
into upstream.
|
|
|
|
while studying GPU lib
|
|
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
|
|
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
|
|
Used this in GPU module to clarify what some "ints" really are.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
This is added in the spirit of the general cycles GLSL system
which is pretty much WIP still.
This will only work on cycles at the moment but generating for blender
internal is possible too of course though it will be done in a separate
commit.
This hasn't been tested with all and every node in cycles, but
environment and regular textures with texture coordinates work.
There is some difference between the way cycles treats some coordinates,
which is in world space and the way GLSL treats them, which is in view
space.
We might want to explore and improve this further in the future.
...also </drumroll>
|
|
https://developer.blender.org/D643
Separates graphics context creation from window code in Ghost so that they can vary separately.
|
|
Those variables would get declared on fragment shader level and since we
use reserved opengl variables, some compilers would throw an error
(NVIDIA allows, some ATI compilers may break). Instead, use a separate
opengl built-in category especially for them. This works on NVIDIA, and
will wait for tests of this commit from ATI users.
|
|
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.
|
|
not do correct partial updates, now it remembers if the opengl texture is a
non-color data texture or not and takes that into account for the update.
Also includes some renaming ncd => is_data for consistency with color space
terminology used elsewhere.
|
|
|
|
color managed.
|
|
|
|
Blenderplayer from crashing on exit and restart.
|
|
"The Blender Foundation also sells licenses for use in proprietary software under the Blender Licens"
also remove NaN references from files that have been added since blender went opensource.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
shader = gpu.export_shader(scene,material)
Returns the GLSL shader that blender generates to produce the visual effect
of material in scene for the purpose of reusing the shader in an external engine.
This function is meant to be used in a material exporter so that the GLSL
shader can be exported entirely. The return value is a dictionary containing the
shader source code and all associated data.
The full documentation is under sphinx.
Warning: there has been an API between the patch and this commit:
uniform['lamp'] and uniform['image'] now return python reference to
ID block instead of ID name as before. The X3D exporter that uses this
function must be adapted.
|
|
|
|
|
|
'const char's,.
Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
|
|
|
|
|
|
global, passing along enable/disable mipmap setting through
various functions instead.
|
|
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
|
