| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
source/blender/blenkernel/intern/armature.c
|
|
|
|
This is complementary change to what we did in master in order to deal
with simulation modifiers.
|
|
Conflicts:
CMakeLists.txt
build_files/scons/tools/btools.py
intern/cycles/util/util_types.h
source/blender/editors/object/object_constraint.c
|
|
This is mainly to make physics modifiers being able to work
with it. For other cases this main is not needed.
|
|
Doesn't mean it's 100% working, but preliminary checks for most of the modifiers
seems to be fine. More intense testing is needed tho.
|
|
|
|
|
|
Conflicts:
source/blender/makesrna/intern/rna_scene.c
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
also replace AT with __func__ since AT expands the full pathname
|
|
new depsgraph.
For now this lives alongside the old callback until porting is complete
and the old callback can be removed.
The modifier cb uses a DepsNodeHandle symbolic type for representing the
current modifier node itself, so it doesn't get into conflict with the
actual DepsNode class. This will also incorporate a pointer to Depsgraph
and possibly other state info internally, so only a single handle
argument is needed.
|
|
|
|
poly/loop ones.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
|
|
A previous bugfix disabled the dynamic paint modifier for orco texture
coordinate evaluation of the modifier stack. However the MOD_APPLY_USECACHE
flag is not a good way to check if the modifier is evaluated for orcos.
Instead I've added a MOD_APPLY_ORCO flag. Also removed a bunch of
applyModifierEM callbacks, none of them served a purpose except for the
subsurf modifier.
|
|
functions, double checled combinations of aspect/scale/shift work as before --- but this reduces the likelyhood of discrepancies for sensor size (corner cases).
|
|
to pass options, instead of having one parameter per boolean flag (i.e. replaces current useRenderParams and isFinalCalc by a single ModifierApplyFlag flag. ModifierApplyFlag is an enum defined in BKE_modifier.h). This way we won't anymore have to edit all modifier files when e.g. adding a new control flag!
Should have no effect over modifier behavior.
|
|
|
|
|
|
|
|
|
|
For sample images see:
http://www.dalaifelinto.com/?p=399 (equisolid)
http://www.dalaifelinto.com/?p=389 (equidistant)
The 'use_panorama' option is now part of a new Camera type: 'Panorama'.
Created two other panorama cameras:
- Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...)
this works as a real lens up to an extent. The final result takes the
sensor dimensions into account also.
.:. to simulate a Nikon DX2S with a 10.5mm lens do:
sensor: 23.7 x 15.7
fisheye lens: 10.5
fisheye fov: 180
render dimensions: 4288 x 2848
- Equidistant: this is not a real lens model. Although the old equidistant lens simulate
this lens. The result is always as a circular fisheye that takes the whole sensor
(in other words, it doesn't take the sensor into consideration).
This is perfect for fulldomes ;)
For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can).
Reference material:
http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdf
http://www.bobatkins.com/photography/technical/field_of_view.html
Note, this is not a real simulation of the light path through the lens.
The ideal solution would be this:
https://graphics.stanford.edu/wikis/cs348b-11/Assignment3
http://www.graphics.stanford.edu/papers/camera/
Thanks Brecht for the fix, suggestions and code review.
Kudos for the dome community for keeping me stimulated on the topic since 2009 ;)
Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
|
|
|
|
|
|
|
|
else if's
|
|
modifiers stack.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
|
|
|
|
|
|
|
|
|
|
|
|
This commit extends limit of ID and objects to 64 (it means 63 meaning
characters and 1 for zero-terminator). CustomData layers names are also
extended.
Changed DNA structures and all places where length constants were hardcoded.
All names which are "generating" from ID block should be limited by MAX_ID_NAME-2,
all non-id names now has got own define called MAX_NAME which should be used all
over for non-id names to make further name migration stuff easier.
All name fields in DNA now have comment with constant which corresponds to
hardcoded numeric value which should make it easier to further update this
limits or even switch to non-hardcoded values in DNA.
Special thanks to Campbell who helped figuring out some issues and helped a lot
in finding all cases where hardcoded valued were still used in code.
Both of forwards and backwards compatibility is stored with blender versions newer
than January 5, 2011. Older versions had issue with placing null-terminator to
DNA strings on file load which will lead to some unpredictable behavior or even
crashes.
|
|
|
|
|
|
|
|
|
|
|
|
CustomData layers only (e.g. UVProject and WeightVG ones).
Also, allow applying to obdata those modifiers, even with shapekeys, but do not allow applying them *as* shapekey (as shapekeys do not have CD layers).
Fix [#29636] Vertex Weight Mix modifier "apply" button don't work.
Note: applying whit shape keys currently always uses base shape, not current one (for apply to obdata as well as apply to shapekey), but this is another topic...
|
|
tri/quad faces). Seems it was harmless, though...
|
|
|
|
MEM_dupallocN does not work with complex layers like CD_MDEFORMVERT ones, so rather use copy func when available.
|
|
|
|
|
|
inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
|
|
|
|
by Gaia Clary.
Rationale: the name was confusing and not always used consistently, and this
map itself is not something that can be layered, rather the map can be used
as texture coordinates in some layered setup.
The original intent was to indicate this contained more than just UV's, but
the game engine settings have already been moved out, and apparently users
didn't really get this from the name anyway.
|
