This was caused by dupli's ObjectEngineData that were not free.
This allocates the data using the instance data manager (no alloc/free between frames). Though the data should be treated as not persistent in this case.
For simplicity we choose to execute the rendering of Opengl engines in the main thread and block the interface.
This might be addressed in the future at least for video rendering.
A drawmanager wrapper (DRW_render_to_image) is called by the render pipeline to set up the Opengl state and then call the specific draw_engine->render_to_image function.
General idea of the fix: skip the whole draw manager callback madness which
was used to tag object's engine specific data as dirty. Use generic recalc
flag in ObjectEngineData structure instead. This gives us the following
benefits;
- Sovles mentioned bug report.
- Avoids whole interface lookup for opened viewports for EVERY changed ID.
- Fixes missing updates when viewport is temporarily invisible.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3028
Main idea is to make specific engine types be a subclass of generic
ObjectEngineData structure.
This required following changes:
- Have extra size argument to engine data allocation function.
Not sure whether there is less error-prone way of doing this.
- Add init() callback to engine data allocation function.
Additionally, added some extra checks to Eevee's engine data getters, so we do
not silently cast lamp data to lightprobe data.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3027
`gpu_texture_try_alloc` invalidates zero-sized textures.
The message in the console is not correct in this case (because it is not due to lack of memory).
This optimisation only works if no material in the scene require the AO pass.
For this either set the AO distance to 0 or both Cavity and Edges factors to 0.
This double the performance of scenes with very high triangle count.
This is because certain part of the engine may require a blank framebuffer to bind textures to.
This is the case when using only array textures, unsupported by DRW_framebuffer_init().
Instead of creating non temp textures only at framebuffer creation, we create them and bind them if their pointer is NULL.
This should simplify the framebuffers creation code.
This modify the selection code quite a bit but it's for the better.
When using selection we use the same batching / instancing process but we draw each element at a time using a an offset to the first element we want to draw and by drawing only one element.
This result much less memory allocation and better draw time.
We need to remove all transform to display during rendering for this to work. The float rect is then color managed when displayed.
This makes all interface colors wrongly displayed because they should be color managed when rendering.
This allows a duplicator (as known as dupli parent) to be in a visible
collection so its duplicated objects are visible, however while being
invisible for the final render.
An object that is a particle emitter is also considered a duplicator.
Many thanks for the reviewers for the extense feedback.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2966
I had to make Eevee draw its scene in the scene pass (before it was doing it
in the background pass). This is not ideal since reference images require
a separation between scene and background.
But it's the best way to solve it now. Clay is working fine.
Users can change the group collection visibility in the outliner
when looking at groups.
Regular collections on the other hand don't have any special visibility control,
if you need a collection to be invisible during render, either don't link it
into the view layer used for F12, or disable it.
This includes:
* Updated unittests - update your lib/tests/layers folder.
* Subversion bump - branches be aware of that.
Note:
Although we are using eval_ctx to determine the visibility of a group collection
when rendering, the depsgraph is still using the same depsgraph for the viewport
and the render engine, so at the moment the render visibility is ignored.
Following next is a workaround for this separately to tag the groups before and
after rendering to tackle that.
It makes more sense to stick to DEG_iterator_object order in name, since we can
have functions to iterate over different entities and we want all of them to
have common prefix.