Levels of detail can be added and modified in the object panel. The object
panel also contains new tools for generating levels of detail, setting up
levels of detail based on object names (useful for importing), and
clearing an object's level of detail settings. This is meant as a game
engine feature, though the level of details settings can be previewed in
the viewport.
Reviewed By: moguri, nexyon, brecht
Differential Revision: http://developer.blender.org/D109
This patch changes most of the reamining degrees usage in internal code into radians.
I let a few which I know off asside, for reasons explained below - and I'm not sure to have found out all of them.
WARNING: this introduces forward incompatibility, which means files saved from this version won't open 100% correctly
in previous versions (a few angle properties would use radians values as degrees...).
Details:
- Data:
-- Lamp.spotsize: Game engine exposed this setting in degrees, to not break the API here I kept it as such
(using getter/setter functions), still using radians internally.
-- Mesh.smoothresh: Didn't touch to this one, as we will hopefully replace it completely by loop normals currently in dev.
- Modifiers:
-- EdgeSplitModifierData.split_angle, BevelModifierData.bevel_angle: Done.
- Postprocessing:
-- WipeVars.angle (sequencer's effect), NodeBokehImage.angle, NodeBoxMask.rotation, NodeEllipseMask.rotation: Done.
- BGE:
-- bConstraintActuator: Orientation type done (the minloc[0] & maxloc[0] cases). Did not touch to 'limit location' type,
it can also limit rotation, but it exposes through RNA the same limit_min/limit_max, which hence
can be either distance or angle values, depending on the mode. Will leave this to BGE team.
-- bSoundActuator.cone_outer_angle_3d, bSoundActuator.cone_inner_angle_3d: Done (note I kept degrees in BGE itself,
as it seems this is the expected value here...).
-- bRadarSensor.angle: Done.
Reviewers: brecht, campbellbarton, sergey, gaiaclary, dfelinto, moguri, jbakker, lukastoenne, howardt
Reviewed By: brecht, campbellbarton, sergey, gaiaclary, moguri, jbakker, lukastoenne, howardt
Thanks to all!
Differential Revision: http://developer.blender.org/D59
Image empties don't actually support mipmaps right now, but the user preference
doubles as a way to disable any kind of interpolating in texture filter and just
show nearest neighbour filter, so for this is a bit more consistent.
Issue was actually that micrometer was not drawing correctly (from r58165), reverted that fix and instead use utf8 drawing for editmode metrics when using a unit system (we already had a similar hack for surfaces and volumes, anyway).
since enough bmesh operations can also take advantage of direct index lookups on verts/edges/faces.
developers note:
- EDBM_index_arrays_init/ensure/free -> BM_mesh_elem_table_ensure/init/free
- EDBM_vert/edge/face_at_index -> BM_vert/edge/face_at_index
- EDBM_uv_element_map_create/free -> BM_uv_element_map_create/free
- ED_uv_element_get -> BM_uv_element_get
Would draw ellipsoid instead, which is not so useful and wrong when
used for rigid body collision shape visualization.
svn merge -r59887:59888 ^/branches/soc-2013-rigid_body_sim
Fixed OpenGL part: in draw_object, when object has some particle systems and none of them render the emitter, and display option is set to show only rendered objects, skip this object.
Note: Cycles matter I did not investigate, looks like a render-engine issue.
In fact, all curve objects were flipped in GLSL mode.
This is because of the way how normals are calculated
for them (inwards vs. outwards).
We might want to make normals consistent all over, but
that would be the bigger change. For ow just made some
tweaks to OpenGL setup.
Thanks Brecht for the review and tests!
Dirty normals already being checked in DerivedMesh.c,
and this things really rather be localized in one
single place than being checked all over the code.
Object.imat isn't always the inverse of Object.obmat, needs to be set before usage
as mentioned in DNA_object_types.h.
Thanks to Miika for tracking down the cause of this bug.
That ended up in tricky code trying to mimic depsgraph
branch behavior API-wise preserving texspace and bound
box calculation compatible with previous releases.
So for now bring cu->disp back to the trunk but keep
texpsace and boundbox APIs the same as in the branch.
This keeps texpsapce and boundbox behavior fully compatible
with previous releases and still makes API the same as
for meshes.
Lattice deformation used to store some runtime data
inside of lattice datablock itself. It's something
which is REALLY bad. Ideally DNA shouldn't contain
and runtime data.
For now solved it in a way that initialization of
lattice deform will create a structure which contains
lattice object for which deformation is calculating
and that runtime data which used to be stored in
lattice datablock itself.
It works really fine for mesh deform modifier, but
there's still runtime data stored in particle system
DNA, It didn't look something easy to be solved, so
leaving this as-is for now.
--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
It used to be a check for ob->bb ? ob->bb : cu->bb but
in fact it doesn't make sense and only makes code more
crappy.
Making displist for mballs and curves/surfaces/fonts
already ensures object has walid bounding box.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
this means in editmode with wire draw, face and vertex normals don't have to be calculated at all.
in most cases the normals are not used so add a flag that makes calculating them only for functions that need them.
also fix face normal calculation for CDDM, was using quad calculation for ngons too.
of the active object in the 3D view. This was due to sharing a global G.moving
flag to indicate that transform is active, now it's only set per transform data
type so different editors don't influence each other.
