Quite striaghtforward implementation, with the only weird thing that for some reason
my video driver wasn't happy with calling the function "clamp" giving some weirdo
shader compilation error messages.
Called the GPU function clamp_val which can handle float and vec3.
That code was mainly needed for the transition period, now we've
got all platforms updated to new OSL.
Plus there are some crucial fixes baking in the current upstream
sources which we'll need to have for the next Blender release.
Even tho it's not 100% clear when we'll switch to OSL-1.6 we'd better
start preparing earlier for this, so we don't spend time on this later.
Plus this code helps troubleshooting some OSL issues, which requires
testing with latest versions of OSL.
It now supports different scheduling schemas: dynamic and static.
Static one is the default and it splits work into equal number of
range iterations.
Dynamic one allocates chunks of 32 iterations which then being
dynamically send to a thread which is currently idling.
This gives slightly better performance. Still some tricks are
possible to have. For example we can use some smarter static scheduling
when one thread might steal tasks from another threads when it runs
out of work to be done.
Also removed unneeded spin lock in the mesh deform evaluation,
on the first glance it seemed to be a reduction involved here but
int fact threads are just adding value to the original vertex
coordinates. No write access to the same element of vertexCos
happens from separate threads.
Ghost depends on glew-mx, so glew-mx should be passed to linker after the ghost.
We're also using spaces for indentation in python, including scons rules.
In cases when the subsurf modifier is the last in the stack and there
are only deformation modifiers before it we can skip doing full orig
vertex lookup.
This is rather common situation here in animatic.
The issue was caused by GLEW MX enabled in SCons by default so
basically previous commit already fixed the crash. But we need
to be safe here.
For now the fix is simple and not that clean, just check if
there's an OpenGL context available and if not we don't do any
GLSL magic.
This is to be cleaned up after some discussion with the viewport
project guys.
Had to fix it by hand (restting them to default values), theme maintainers,
please check your theme from time to time and track such ugly 'pitch black' fields.
And we devs should run theme update script much more often too - will do in next commit!
This mainly happens when over-saturating already saturated color.
After some discussion with Campbell and loads of tests we decided
to clamp the result RGB color. As an alternative we might want to
clamp corrected HSV values instead, but that would lead to some
larger changes in the render results.
TODO: The same is to be done for compositor nodes.
Add simple uvs now does a cube unwrap and pack operation. Result is not
optimal by far but it should not result in crashes and it will be quite
usable for simple cases.
The root of the issue comes to the way how we sample the gaussian filter in
RE_filter_value(). We need to scale x to -3*sigma..3*sigma segment in order
to get the whole bell.
The old code tried to do it, but failed dramatically, plus it used some weird
gaussian sampling formula. Replaced it with much more clear one, which gives
proper blur now.
There's no visible different in AA sampling in BI render tho.
Other filters like Mitchell still tends to give wrong square shaped blurs,
but they're much more difficult to resolve because they're just wrong in
the code -- for some reason smaller kernel size means more blur. Let's solve
this later.
Constraint space conversion ignores object scale, which is OK in most cases. But here,
we are converting a normal from world to local space, and when later converting it
into target space to actually do the BVH raycast, we use TransformSpace which
does applies objects' scaling to normals, as expected.
Best solution here is to also take object's scale into account when converting
from local to world space.