- User Since
- Jan 3 2003, 6:23 PM (789 w, 5 d)
They have the same solution, I have a work in progress fix for the other one, will finish that.
Mon, Feb 19
- New scatter and absorption color parameter interpretation.
- Blackbody Tint parameter to decoupled it from Emission parameters entirely.
- Rename Emission to Emission Strength.
I think the name Principled Volume is ok, it doesn't explain the whole thing but for most users adding more technical terms to the name is not so helpful. It's better explained with text and renders in the docs. Other renderers also typically called it just "Something Volume".
I did some more testing with the scattering and absorption colors and adjusted the code. Here's the new behavior, with and without volume bounces. The colored planes in front show the scatter/albedo and absorption/transmission color parameters.
Yes, I forgot to update part of the code, will fix.
This shouldn't have been closed yet.
Something like this should work:
Sun, Feb 18
Ok, so this is about GLSL material display.
Are we talking about the previews in the node editor? Those are not expected to update when changing the object index, they are only previewing the material in isolation, the object(s) in the scene have no influence.
flame_smoke_color controls the color of smoke produced by fire, and this simulation has no fire so it has no effect.
Sat, Feb 17
Emission and blackbody are most likely to change still. The way volume attribute names are exposed I'm also not entirely sure about, but it's pretty useful to have them as sockets so that they can also be exposed in group nodes. Eventually we want almost all node options to be available as sockets anyway for that reason.
Update to fix all known bugs in the original patch.
Fri, Feb 16
It seems to be crashing in the AMD OpenCL code. Please try running clinfo from the command line (install package if needed) and attach its output here, so we can see the exact OpenCL implementations and versions installed.
It makes a bit more sense with the default empty cross shape, then the image is in the corner.
Please create a new bug report, with attached .blend and exact steps to redo the problem.
Thu, Feb 15
The crash and uninitialized memory were different issues, but both should be fixed now.
Use .blends from all lib/tests directories, because why not. If we ever store
reference screenshots in svn then it might make sense to limit the tests, but
for now it seems pretty convenient for regression testing blender2.8.
Also add WM_OP_INVOKE_REGION_CHANNELS I think. Otherwise looks good to me, I don't think leaving out the preview and channels was intentional.
One thing I forgot to mention, running these tests pops up Blender window while running so you can't do anything else. It would be nice if we run them in the background, or perhaps place the Blender window below others without getting focus. But I'll leave that for the future when I'm sufficiently annoyed by it.
Wed, Feb 14
This is what the report looks like (comparing master and blender2.8):
Let's close this one then.
Tue, Feb 13
It's indeed a lot of memory usage for stereo. Maybe there's a couple intermediate buffers that can be shared? But no easy solutions I guess.
Rebase after committing code cleanups to blender2.8.
I was planning to do this already before D3057 came up. I think it's a good improvement regardless if we end up drawing in a single offscreen context or not, because of the other advantages.
- Already in the blender2.8 branch, stereo Eevee drawing causes continuous redraws and only shows a single noisy sample. The problem is that the 3D viewport only has a single GPUViewport, which is constantly switching between the two views and resetting, so it never makes progress. Perhaps the 3D view should have a second GPUViewport for stereo drawing?
- Many operators call view3d_operator_needs_opengl. It currently sets up glViewport, glScissor and matrices on the screen framebuffer, which doesn't have a depth buffer anymore. I added offscreen depth buffer drawing at some point in the past, but I need to figure out to what extent that is used now and what other kind of OpenGL drawing operators need this for. The fact that we have both new and legacy drawing code makes it difficult to understand, is there a reason we still have the legacy draw code?
GHOST: remove support for multisample, depth, stencil and preferred swap method.
Let's consider this resolved for now, if further issues are found please open a new bug report with .blend to repro. This fix will be in 2.79a.
Also a typo: WITH_CYCLES_DEVICE_OPENC should be WITH_CYCLES_DEVICE_OPENCL.
That's all fine with me, except for WITH_CYCLES_DEVICE_MULTI. I would remove that option, it only makes things fail when you try to render with multi-device, and I see no reason to add the code complexity for properly adjusting the UI to hide multiple devices.
Can we turn this into a Random output that hashes the index to a 0..1 float, for consistency with Object Info?
Note that setting WITH_CUDA_DYNLOAD=OFF is purely a debugging feature, unless you want to debug CUDA kernels there is no reason to change the default. The option could get a better name and description though.
Cycles should compile fine without CUDA installed already, but maybe something broke with the recent changes? Which platform and cmake options are giving a problem?
Mon, Feb 12
Yes, it only affects the small material icons.
With the latest fix we will now compute the icons previews with a fixed background color. It's not possible to load low resolution map for a .hdr file, we'd have to load in the full resolution anyway and then scale it down which would be slow too.
Thanks a lot for the test file, it doesn't matter if it's big or not created from scratch.
This is by design currently. Cycles viewport rendering always uses viewport settings. This ensure quick redraws using the same meshes that are drawn in other viewports.
Just to repeat, we are not able to reproduce this issue currently. This is the information we are looking for:
Great, this is how I imagined to work. Some code comments, even though this is work in progress and you might already be aware of some of them.
Sun, Feb 11
Not at the moment, but maybe in the future.
Sat, Feb 10
Overall this make a lot of sense to me.
This should be fixed now, once the build finishes:
The Normal pass in Blender Internal is in camera space, the one in Cycles is in world space. The change in Cycles was by design, to be more consistent with other renderers. With a fake lighting in the compositor for example, world space normals mean that light will keep coming from the same direction as the camera moves.