The ultimate goal is to only allow the rasterizer to handle OpenGL and bf_gpu
calls. This commit creates a RAS_ILightObject interface and a RAS_OpenGLLight
implementation.
These types of meshes do not use material caching, and thus only the first created
material would be saved, but subsequent ones were not. Those subsequent materials
were then not being freed. Now we make sure to track all of the materials.
Note: Meshes that cannot make use of material caching (no materials or using face textures)
can still use up a large amount of RAM since a material is created per face.
If bge.logic.addScene() could not find the scene to add it would add the
first scene again, which is just silly. Now, if no scene is found, a warning
is printed and nothing is added.
GPC_Canvas::GetWindowArea() and KX_BlenderCanvas::GetWindowArea() are tracking two
different things. The 2d filter system doesn't actually need the window area and
can get by just using the viewport dimensions, which it now does. The GetWindowArea()
mess should probably be cleaned up.
Non-camera objects are not supported as cameras, and trying to use them
just causes memory errors (some bad typecasts are involved). When converting
a Scene Actuator, only use the object as a camera if it is actually a camera.
Also, the logic brick UI now filters for camera objects, which should help
avoid confusion.
The "Cast Shadows" worked as expected, but it can cause problem in some cases.
For example, when using strand render, we need disabling only buffer shadows,
but the previous changes made that impossible. "Cast Shadows" should be added
as a newly created option.
Since threaded object update we've disabled in-place
curve evaluation (in cases when applying curve modifier
with target curve non-evaluated yet).
This requires game engine to take care of DAG and object
evaluation (currently it's designed to export only objects
it able to render).
This workaround will make sure that curve_cache for curves
is up-to-date.
This allows us to make materials that don't cast ray shadows.
Turning off this property can reduce the rendering time slightly.
Note: RNA path is changed to "use_cast_shadows" as well. The older
path "use_cast_buffer_shadows" still can be used as its alias, but
it will be removed after updating some addons.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D272
Was a regression since avg_frame_rate changes.
Didn't find reliable way to get stream duration which will
work with both FFmpeg and Libav so added some freaking black
magic to distinguish one from another.
This reverts commit 6a473305af22468abfc4c4f8f3002dc0a97fffd7.
Caused T38296, need to investigate this further but for now
better not leave blender in unstable state.
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
This mode is designed for passive 3D TV: the viewport is split
horizontally - left eye above, right eye below - but the original camera
viewport is squashed in each half (with half the vertical resolution).
This is necessary to restore the aspect ratio in the 3D output because the TV expands each half to the full screen size.
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
Issue was caused by recent image cache rewrite and root of
the issue goes to the fact that blender player doesn't
initialize cache limiter and it uses 32meg of memory only.
This leads to infinite image loading/freeing.
For now disabled cache limiter in game engine, this brings
back old behavior.
In theory we might be smarter here, but better caching
policy is to be discussed.
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
