| Age | Commit message (Collapse) | Author |
|---|
|
gpu_draw: skip color management for textures declared as 'non-color'.
New reserved names in 2D filters: bgl_ObjectTextureX (X=0 to 4) to
access texture channels 0 to 4 of the object on which the 2D filter
is defined.
Force U.use_16bit_textures to 1 in the blender player to give access to
floating point textures in the 2D fitlers shaders.
bge.logic.setOffScreen(True) to define and use a floating point offscreen
render buffer of the same size than the framebuffer in the main BGE loop.
Useful to get floating point results from 2D filters. The offscreen render
buffer will automatically be used by bge.texture.ImageViewport if it's enabled.
It is legal to call bge.logic.setOffScreen(True/False) to disable and reenable
the framebuffer on a frame by frame basis.
New refresh mode for bge.texture.ImageViewport and bge.texture.ImageRender
objects:
iv.refresh(buffer, mode)
mode = "DEPTH" to retrieve floating point depth buffer
= "RG32F" to retrieve red and green channels as floating point.
= "RGB32F" to retrieve red, green and blue channels as floating point
= "RGBA32F" to retrieve red, green, blue and alpha channels as floating point.
For ImageViewport and ImageRender, refresh() bypasses all filters and object
options and retrieve directly from the frame buffer or render buffer.
|
|
This prevented the Force Field Curve Shape of working
|
|
Probably some leftover from much older code?
|
|
|
|
|
|
Please provide valid description for SurfaceDeform modifier tooltip.
Such place-holders should not pass final checks before merging in master!
|
|
object_get_derived_final shouldn't have been assuming mesh objects.
It's even valid to use a curve as a target for a shrink-wrap modifier.
|
|
|
|
Utility to execute a string and get the resulting string,
matching BPY_execute_string_as_number.
Not used just yet but generally useful function.
|
|
|
|
|
|
|
|
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader maybe).
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2510
|
|
Meshes w/o modifiers wouldn't have their derived mesh applied.
Check was to avoid crash but its in fact meaningless,
since the modifier might be disabled, or there may be virtual modifiers.
|
|
|
|
Needed to read user-preferences from in-memory startup.blend
Also skip data-blocks when reading preferences.
|
|
Previously it would always load into 'U' global.
Needed for loading & merging template preferences.
|
|
|
|
Not sure why I did not put those from start... Actually *not* having an
undo point here can be problematic, since undoing some previous action
was trying to restore from bad pointer (I think) in UI, generating
asserts.
Note however that it's not a 'pure' undo, in that you may not find your
linked data in exact same state as before deleting it, after an undo,
since it actually implies *reloading* the deleted libraries (and not
restoring from a previously stored memory dump).
Reported by @sergey, thanks.
|
|
There is no way currently to prevent the option from showing in menu, so
instead report a warning to user (and curse again current nightmarish
system of operation in outliner...).
Reported by @sergey, thanks.
|
|
Need to expand all object's dupli-groups, not only the dupli-groups
of objects directly linked to the scene.
|
|
|
|
Lower risk of forgetting to update some values here.
|
|
|
|
Needed so we can load and free non-global user preferences.
|
|
When you use typedef'ed enum, you need to define all supported values
explicitely in enum, else compiler goes grumpy...
|
|
|
|
Internal change needed for template support.
Loading the user preferences first so it's possible
for preferences to control startup behavior.
In general it's useful to load preferences before data-files,
so we know security settings for eg.
|
|
Reported by Pablo Vazquez (venomgfx) over irc.
|
|
Planning to use this util function in 2.8 for doversioning (to communicate converted layers)
|
|
|
|
depsgraph
The thing i'm really starting to hate is the requirement to specify both
operation code and node type. Seems to be duplicated enums without real
need for that.
|
|
Needed since the active operator isn't ensured to be the last.
|
|
(use unique id for bones with same name in different armatures)
|
|
|
|
This addresses an issue raised by D2453 -
that there was no way to check if operators are run
multiple times in a row.
Actions are still ignored that don't cause an UNDO event.
|
|
This is needed so we can tell if operators are executed repeatedly.
|
|
armatures. Co-authored-by: Gaia <gaia.clary@machiniamtrix.org>
|
|
Was using some threaded queue on top of task pool, tssk...
Now using properly task pool directly to crunch chunks of smooth fans.
No noticable changes in speed.
Tried to completely get rid of the 'no threading with few loops' code,
but even just creating/freeing the task pool, without actually pushing
any task, is enough to make code 50% slower in worst case scenario (i.e.
few thousands of simple cube objects).
|
|
|
|
meshes have autosmooth enabled.
The root of the issue was in custom normal code, so far it assumed that
we could only have one cyclic smooth fan around each vertex, which is...
blatantly wrong (again, the two cones sharing same vertex tip e.g.).
This required a rather deep change in how smooth fans/clnor spaces are processed,
took me some time to find a 'good' solution.
Note that new code is slightly slower than previous one (maybe about 5%),
not much to be done here, am afraid.
Tested against all older report files I could find, seems OK.
|
|
We do can have some vertices to split, while not having any edge (think
about two cones sharing the same tip vertex e.g.).
|
|
Not user visible, needed for switching templates.
|
|
|
|
|
|
|
|
call
|
|
|
|
Use expanded names for bmesh primitive operations
(urmv jvke semv jfke).
Use 'bmesh_kernel_' prefix,
these functions aren't intended for wide use so favor readability.
Remove BM_face_vert_separate,
it wasn't used and only skipped step of finding correct loop of face.
|
|
|
