As a followup for the previous commit, do the same thing for the insert/delete
keyframe button operators as is done for the clear keyframes op. There really isn't
much need/reason for conducting the looping there, as those functions natively
handle this themselves already.
On second thought, the previous commit was just adding additional complexity which
wasn't needed, as the operator was wasting effort by doing this looping itself.
Moral of the story: Make sure that size_t is used whenever pointer
arithmetic is involved. For images, that basically means whenever any
squared dimensions are involved. Casting an operand to size_t early in
the operation is usually sufficient to force the entire operation to
size_t.
There might still be places lurking where we don't support this
correctly. This has been tested with render pipeline, quite a few image
functions (meaning we can paint on such images now, albeit somewhat
slowly ;) ) and export to jpeg. Too many places in code to check so I
guess we'll be handling cases as they come.
Don't try this at home unless you have an immense ammount of RAM.
First GPixel render of suzanne in the multiverse can be found here:
http://download.blender.org/demo/test/suzanne-billion-pixel.jpg
Can be viewed from blender (takes about 3.3 GB after loading but may
take more during loading so 8GB might be more safe to try this).
Issue was caused by de-referencing NULL pointer, rres did not have any
views because nothing was rendered yet.
Needs more closer look about where else such a de-reference could happen.
We can now scale from 32px up to 256px (default has been upgraded to 128px).
Thumbnails are now generated as 'large', i.e. 256px.
Previews are scaled up if necessary, unlike icons (for folders or files without preview images).
Note that .blend thumbnails themselves remain in 128px for now (they are embeded in .blend files,
not quite sure we want to make them four times bigger...).
Patch by DMS (Yaron Dames), with final edits by myself.
Reviewers: mont29
Subscribers: Severin, mont29
Differential Revision: https://developer.blender.org/D1260
Originally I wanted to get rid of RenderResult->rect* entirely, but it's
convenient to have for temporary structs.
This patch makes sure they are used only when really needed, which
should help clearing the code out.
(they are needed when using RE_AcquireResultImage() - which produces a
RenderResult with no RenderView)
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1270
In this case we can calculate an offset without worrying about
perspective correction. Unfortunately if looking from a camera we still
have depth issues here. There's no really general case that can fix this
so I'm leaving this as is.
The reported crash case seems to be caused by freeing compiled Python
objects in a thread. Now this issue is avoided by allocating a buffer to
store a Python script and using BPY_string_exec() to run the script. This
makes it unnecessary to repeatedly create and destroy Text data blocks.
Many thanks to Campbell Barton for his help on the bug fix.
Issue is zfighting with wire of mesh when parts of the mesh are close
together. We can make this slightly better by reducing the offset,
however this offset is calculated pre-perspective division and can vary
greatly with distance. Correct approach would be using polygon offset,
however we draw mesh wireframes as lines, (not polygons with polygon
mode line) so this approach will not work.
Alternatively, we could set an offset in a shader, however we don't have
code for that either.
would fail on coplanar faces (or smooth verts).
Loop remapping is really a tricky topic... For now, we enhance a bit more
our Frankenfunc by using distance between dest and source polygons as
fallback in case we have too much similar normals...
Probably not a perfect solution, but should be robust enough I hope.
One core question remains open though: do we want to stick to 'use only seams
to detect UV islands'? This makes things much simpler, but will obviously fail
in case of actual islands without matching seams. :/
