We cannot use FLT_MAX as initi distance for raycast...
Renamed TRANSFORM_DIST_MAX_RAY to BVH_RAYCAST_DIST_MAX, moved it into BLI_kdopbvh,
and use in RNA raycast callbacks (and all other places using that API).
In fact, code would behave strangely here with any negative value, applying a 'wrapped positive clamping'
(comes from original 2.5 commit feature, rBfafbd9d71b95776d1c7583476de74fccefab7f10)...
This commit is conservative - it keeps same behavior for all particle properties affected by textures,
except for size and length, where we apply a real [0, 1] clamping.
Easy to change in future in case new odd cases popup.
Screenshot ignored errors, some render code printed 'Saved' without checking for failure.
note: errno is now cleared from IMB_saveiff so all callers don't need to.
Active color wasn't copied over if it differs from what the user plugged
in in the UI. Also use a darker color for the default color so smoke
doesn't doen't appear too bright.
Reported in IRC by mib2berlin.
In fact, it was not working with BI either - 'UV from dupli' would always take active UVLayer,
not render_active one.
Fixed now for both Cycles and BI, and for both particles and 'simple' dupli_face.
Code 'localizing' the node of an ID (a material, here) was kind of a joke,
setting id.lib to NULL is not enough, by far! Now calling ntreeMakeLocal().
And ntreeMakeLocal was also missing indirect->extern switch for its directly used IDs,
which explains why they were lost after a save/reload.
Note that here again, a big part of this 'localizing' code should be made generic
using library_query stuff, but this is for id-remap, not current master...
This change is for a few reasons:
- it works with color, and (therefore) will need to be color managed, at
some point. This will be much easier to do if the code is closer to the
actual color management code (in Blender's core, so to speak).
- it has nothing to do with the actual fire simulation, as it is just
used to create a lookup table
- it can be reused for other purposes (i.e. in Blender internal
renderer, if people are interrested in a blackbody node à la Cycles)
- cleanup: some functions (`contrain_rgb`, `xyz_to_rgb`) already exist
in BLI
Reviewers: brecht
Reviewed By: brecht
Subscribers: brecht
Differential Revision: https://developer.blender.org/D1719
As in the title. In the smoke version, there was also an extra
'for_render' parameter that wasn't used, and wasn't used by the callers
either, so it was removed altogether.
Reviewers: brecht
Reviewed By: brecht
Subscribers: brecht
Differential Revision: https://developer.blender.org/D1718
Also added a DEBUG_TIME macro in the related files to comment time funcs out.
Reviewers: brecht
Reviewed By: brecht
Subscribers: brecht
Differential Revision: https://developer.blender.org/D1717
- Fixed a bug that the sound when changed in the properties panel was not updated.
- Added the option to make a sound mono while adding a sound strip.
- Added the option to make a sound mono in the sequencer properties panel.
Related bug report: T47140
Issue is with rounding up of length reported by audaspace for audio part - when it matches nearly exactly
the actual video length, using ceil() would make it one frame longer. Now apply a small (0.0001 frame)
negative offset to prevent this effect.
When importing new movie strips into the sequencer, the scene's frame rate
will now be adjusted to match that of the movie being loaded by default.
To get the old behaviour (e.g. if importing a clip into an existing project),
disable the "Use Movie Framerate" option in the file browser when selecting
the strip.
This change is designed to solve the common problem that users trying to import
video clips will forget to adjust the frame rate before importing the clip, thus
causing the sound and video strips to be out of sync (as the sound strip ends
up longer/shorter than the video stream).
This mainly adds bpy.data.user_map() method, which goes over the whole Main database
to build a mapping (dict) {ID: {users_of_that_ID}}.
Very handy to check and debug ID usages, but could also be really valuable for py addons
creating temporary scenes, or some exporters, etc.
Note: current code in master's libquery misses some IDs (and reports some it should not,
like nodetrees), this is fixed in id-remap but still needs serious review before going to master.
This basically means that current bpy.data.user_map() **will not** report a complete and exhaustive
state of dependencies between IDs. Should work OK in most cases though.
Original work/idea comes from id-remap branch, was heavily reworked by @campbellbarton
and myself for master.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D1678
Note that this has little impact on current master - yet it allows to fix the 'Image Editor' bug
(open image in editor, use same image in texture, delete image from texture, image us is 0 and
red in image editor...) and probably a few other similar cases.
But that change is mandatory to get a proper handling of ID deletion/reamapping/reloading/etc. as done in id-remap branch.
Instead of just adding a user if none already present, new code use two new ID tags to get a three-states status:
- Normal: nothing changes.
- Needs extra user: we know that ID needs an extra user, so we take of never going down to 0 in 'real' usercount handling.
- Has extra user: we do have increased that ID usercount to get our needed extrauser.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1696
Looptri are not mesh data, they are allocated and built for PBVH only, and totally 'local' to it,
so duplicating like we do for verts & co leads to leaking memory.
It also fixes another issue (crash) related to symmetric editing.
Quite involved, we (try to!) fix complete broken logic of parts of particle code, which would use poly index
as tessface one (or vice-versa). Issue most probably goes back to BMesh integration time...
This patch mostly fixes particle editing mode:
- Adding/removing particles when using generative modifiers (like subsurf) should now work.
- Adding/removing particles with a non-tessellated mesh (i.e. one having ngons) should also mostly work.
- X-axis-mirror-editing particles over ngons does not really work, not sure why currently.
- All this in both 'modes' (with or without using modifier stack for particles).
Tech side:
- Store a deformed-only DM in particle modifier data.
- Rename existing DM to make it clear it's a final one.
- Use deformed-only DM's tessface2poly mapping to 'solve' poly/tessface mismatches.
- Make (part of) mirror-editing code able to use a DM instead of raw mesh, so that we can mirror based on final DM
when editing particles using modifier stack (mandatory, since there is no way currently to find orig tessface
from an final DM tessface index).
Note that this patch is not really nice and clean (current particles are beyond hope on this side anyway),
it's more like some urgency bandage. Whole crap needs complete rewrite anyway,
BMesh's polygons make it really hard to work with current system (and looptri would not help much here).
Also, did not test everything possibly affected by those changes, so it needs some users' testing & validation too.
Reviewers: psy-fi
Subscribers: dfelinto, eyecandy
Maniphest Tasks: T47038
Differential Revision: https://developer.blender.org/D1685
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
Vector mapping node was doing some weird mapping of both original and mapped
coordinates. Mapping of original coordinates was caused by the clamping nature
of the LUT generated from the node. Mapping of the mapped value again was quite
totally obscure -- one needed to constantly keep in mind that actual value will
be scaled up and moved down.
This commit makes it so values in the vector curve mapping are always absolute.
In fact, it is now behaving quite the same as RGB curve mapping node and the
code could be de-duplicated. Keeping the code duplicated for a bit so it's more
clear what exact parts of the node changed.
Reviewers: brecht
Subscribers: bassamk
Differential Revision: https://developer.blender.org/D1672
Also rearranged code here to not issue a draw call (explicit flush) per
face and not set shader per face either when stippled drawing is mixed
with regular drawing. Not good at all for performance.
This snippet creates a white balance modifier for the video sequence editor. It is useful for everyone who likes to set a new white point in the video source (easily via the eyedropper). Just select a point in the source file where you know that it should be white. The algorithm will then shift the colors towards your new white point.
See attached the image for a quick demo.
{F270576}
Reviewers: psy-fi
Reviewed By: psy-fi
Subscribers: Blendify
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1698
