Did a full compile of debug build with C++11 enabled, it all passed compilation
apart from some deprecated type used in GE's Video Texture. Solved it inside of
ifdef block now.
In the future we should uncomment the MSVC part of it, it should all be safe and
correct (MSVC2013 does not define new C++ version but supports C++11). The reason
it is commented is to have absolutely no effect on the upcoming release.
Behavior is similar to python's set.pop(), it removes and returns a 'random' entry from the hash.
Notes:
* Popping will return items in same order as ghash/gset iterators (i.e. increasing
order in internal buckets-based storage), unless ghash/gset is modified in between.
* We are keeping a track of the latest bucket we popped out (through a 'state' parameter),
this allows for similar performances to iterators when iteratively popping a whole hash
(without it, we are roughly O(n!), with it we are roughly O(n)...).
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1808
This is an attempt to improve the User preferences panel for the 3DView. I made 2 changes:
- I reordered the sequence of properties by grouping them into more logical groups as it made sense to me. Please indicate where to rearrange the order if necessary.
- Then i added some changes in the code to get the groups better arranged visually. I am pretty sure that this can be done much better, more clever, more generic, whatever. This is just what i could figure out on my own so far.
Reviewers: aligorith, sergey, gaiaclary
Subscribers: sergey
Projects: #user_interface
Maniphest Tasks: T47295
Differential Revision: https://developer.blender.org/D1757
Those warnings are trigerred by stl classes in OCIO's public interface.
To quote MSDN: "C4251 can be ignored if you are deriving from a type in
the Standard C++ Library"
This is the only instance where those warnings hunts us, so for now we
can keep it all local in intern/opencolorio but this might be changed
in the future.
There's no need to mix ints and size_t here at all
because all the values fits into integer.
It's unlikely we'll be re-bundling Carve, so didn't
bother with the patchset.
The idea now is to have FFmpeg/OIIO headers listed after
the system ones. This is because FFmpeg/OIIO might define
some constants with the same name as the ones from math.h.
FFmpeg/OIIO has ifdef around defines, but math.h doesn't
check whether constants were already defined or not, which
causes some noisy warnings.
The problem is that node trees (such as the Material, Lamp, and Compositor node trees)
are stored as "nested node trees" on the affected datablocks. They are particularly
troublesome to deal with, as the are not easily identified, and also cannot be easily
mapped back to the ID's which actually own them. As a result, the usual automated
methods do not work when dealing with these!
Only Driver FCurves with named shapekeys (instead of shapekey indices) was
getting picked up by the UI code for testing whether a property had drivers
or not. So, while this version patching code worked when it was initially
written for the 2.4x -> 2.5 transition, some subsequent changes ended up
breaking this. As this stuff is not used often, the breakage wasn't noticed.
* Remove unnecessary big margins after triangle icons (esp. for keymap items they where waaay to big)
* Remove ugly margin after "Foo (Global)" entries
* Add little margin after expanded key maps
Actually, 3 issues here:
* Keymap items of "Foo (Global)" maps weren't indented enough
* Items after a opened "Foo (Global)" map were indented too much (col was overridden then).
Seems to be some compiler fault which leads to a wrong flag being used,
making it so wrong number of samples is used for the background.
This should in theory fix issue reported in T47213.
This patch adds a python method to get openGL bind code of material's texture according to the texture slot.
Example:
import bge
cont = bge.logic.getCurrentController()
own = cont.owner
bindId = own.meshes[0].materials[0].getTextureBindcode(0)
Test file: http://www.pasteall.org/blend/40679
This can be used to play with texture in openGL, for example, remove mipmap on the texture or play with all wrapping or filtering options.
And this can be used to learn openGL with Blender.
Reviewers: TwisterGE, kupoman, moguri, panzergame
Reviewed By: TwisterGE, kupoman, moguri, panzergame
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1804
The issue here was actually somewhere else - the attached scene from the report used a light falloff node in a sunlamp (aka distant light).
However, since distant lamps set the ray length to FLT_MAX and the light falloff node squares this value, it overflows and produces a NaN
weight, which propagates and leads to a NaN intensity, which is then clamped to zero and produces the black pixels.
To fix that issue, the smoothing part of the light falloff is just ignored if the smoothing term isn't finite (which makes sense since
the term should converge to 1 as the distance increases).
The reason for the different results on CPUs and GPUs is not perfectly clear, but probably can be explained with different handling of
Inf/NaN edge cases.
Also, to notice issues like these faster in the future, kernel_asserts were added that evaluate as false as soon as a non-finite intensity is produced.
