- User Since
- Jul 9 2014, 7:45 PM (375 w, 4 d)
This will be tackled next week.
Fri, Sep 17
Shadowing (or visibility) is not generally separable from shading but for realtime rendering purpose we consider this to be true as we only have shadowing information for one direction.
Thu, Sep 16
Mon, Sep 13
Sun, Sep 12
Sat, Sep 11
This is exactly what I had in mind. If there is no more memory leak, I think we are good to go.
Fri, Sep 10
@Julian Eisel (Severin) I do agree that creating a dedicated function call instead of using a registered callback is preferable. Just doing something like ED_annotation_draw_view3d should be enough and the XR draw routine should decide what to draw.
For me it's good to go.
Thu, Sep 9
I have no issue with the drawing being a callback in the draw manager.
I looked at the addons that come with Blender and noticed that they all use the draw_texture_2d utility to draw textures. So I just edited this utility to avoid breakage.
Avoiding breakage only for our addons is not enough to me. This also complicates the usage of the API for simple scripts. Also depth texture do not have filter by default.
Wed, Sep 8
Therefore, gpu.types.GPUTextureState would only be useful for the uniform_sampler(...) method. Which makes me wonder if creating a new object for a single method wouldn't be too much.
This is a valid concern. The benefit of using an object is that it's easy to setup once and reuse, have error checking on assignment, and it replaces all states at once where distinct parameters would only override some.
The issue with changing the texture parameters is that if the texture comes from Blender (i.e: image Texture) the state changes will propagate to the internals of blender. I would like to avoid this case.
My point is that it should not be a flag but an object with different properties. This way it's much cleaner to setup.
Tue, Sep 7
First of all, impressive result. Do note that I'm not familiar with how OpenSubDiv works.
Seems to be the good thing to do to fix the issue. I'm just not sold on the naming used. But feature wise it's good to go.
Mon, Sep 6
Fri, Sep 3
This has the side effect that if a previously written code uses uniform_sampler it will now always override the texture internal sampler parameters which are set by default.
But since there is currently no possibility to modify the internal texture state using PyGPU, I would not consider this a major issue.
Looks good to me. Patch is quite straightforward.
Yes, this is unsupported for now. However, I'm not sure even if Gpencil should have this functionallity. It is an easy feature to add though, since Gpencil materials now support creating "holes".
Did simple tests. Seems to work fine with EEVEE and other viewport engines.
Wed, Sep 1
I'm not sure that exposing all enums is the way to go. It sure was the easiest option for your testing.
Tue, Aug 31
Selection as a whole is getting a bit too much inside the draw manager but it's a lesser evil than having a dedicated selection engine for overlays.
Maybe one day we will just have this dedicated engine with simpler drawing for overlays but I doubt.
Mon, Aug 30
Nice find! Thanks for the time you put into this fix!
Wed, Aug 25
Aug 20 2021
Aug 13 2021
Aug 11 2021
Maybe mip_count is better then. These are the number of mipmap levels. mips being plural was just shorter.
Aug 10 2021
Aug 5 2021
Aug 3 2021
Jul 23 2021
Jul 22 2021
I don't see any issues either. I think it is better to introduce the change now to track any potential issue down the road.
Jul 19 2021
All I see should work fine, as long as the objects passed for evaluation are tagged as dupli objects (BASE_FROM_DUPLI).
The issue is that shadow mapping (the shadow technique used in EEVEE) is not a perfect shadowing solution and will always leak a small amount of light.
Jul 17 2021
What I don't really like:
- Builtin Block definitions are not in the shader itself: Having it declared in the compilation call makes it hard to follow. For this I would prefer to have a sort of include system.
- Depending on the complexity, the struct declaration could be shared just like in eevee-rewrite branch. Not sure if it is a problem if the structs are only a handfull.
- Builtin Blocks are monolithic. Impossible to reuse. For instance I would keep a ViewBlock and a ModelBlock separated and even not managed by the shader, only by the GPUMatrix module. I would put the srgbTransform and color uniforms into the same block.
Jul 6 2021
Jul 3 2021
Jun 29 2021
Another thing to not forget is how does one updates a pyGPU shader to this version.
Jun 22 2021
Jun 21 2021
Jun 17 2021
Jun 15 2021
Dirty but better than nothing.
Jun 14 2021
Jun 13 2021
Jun 11 2021
The patch is good feature wise. I just have a few style comment.
Jun 8 2021
Jun 6 2021
Jun 4 2021
Jun 3 2021
Jun 2 2021
I've investigated and.... it was a bug that has been fixed 2.93. Basically the clamp on SSR rays was not applied to really sharp refractions in 2.92. In 2.93 they are correctly clamped to avoid discrepency with rougher surfaces.