Python API (parent task) #56351

New Issue

Brecht Van Lommel · 2018-08-13T13:57:30+02:00

Brecht Van Lommel commented

2018-08-13 13:57:30 +02:00

Python API tasks for the 2.80 release.

Documentation

- Gizmo and tool API
- Object mode operator working on selected, visible, editable objects
- Mesh edit mode operator working on multiple objects.

Missing APIs

Note: this won't be done for 2.80!

- Export objects at render resolution. Needs function to get/clear render resolution depsgraph for a scene and view layer?
- Too difficult to set new collection as active

Python API tasks for the 2.80 release. ### Documentation * - [ ] Gizmo and tool API * - [ ] Object mode operator working on selected, visible, editable objects * - [ ] Mesh edit mode operator working on multiple objects. ### Missing APIs *Note: this won't be done for 2.80!* * - [ ] Export objects at render resolution. Needs function to get/clear render resolution depsgraph for a scene and view layer? * - [ ] [Too difficult to set new collection as active ](https://devtalk.blender.org/t/set-active-collection/2409)

Brecht Van Lommel commented

2018-08-13 13:57:30 +02:00

Added subscriber: @brecht

blender-admin commented

2018-08-13 13:57:30 +02:00

blender/blender-addons#56621 was marked as duplicate of this issue

blender-admin commented

2018-08-13 13:57:30 +02:00

#54626 was marked as duplicate of this issue

Alfonso Annarumma commented

2018-08-16 13:12:26 +02:00

Added subscriber: @AlfonsoAnnarumma

Andrew Hale commented

2018-08-27 10:26:14 +02:00

Added subscriber: @truman

Jacques Lucke commented

2018-11-07 18:11:08 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2018-11-09 13:57:31 +01:00

About the Draw API:

I'll add more documentation for GPUVertBuf, GPUVertFormat and GPUIndexBuf. They are not needed in many cases though.
I have no idea what gpu.select is useful for. So I can't really help documenting it right now. Maybe we should just leave this module private for now.
Personally I find it a bit confusing to use the gpu.matrix module. It's unclear to me what I depend on when I use it. Unfortunately the module has to be used when you want to use the builtin shaders. I'd expect that Blender can derive the view/projection matrix from the context I just have to provide the model matrix. Not sure what's the best way to handle it.
Maybe gpu.shader could be merged with gpu.types.GPUShader? Ideally it would have something like this: gpu.types.GPUShader.FromBuiltin(...), shader.vertexcode, shader.fragcode and shader.geocode. This also means that we'd have to store the source code for user defined shaders, but that would not be too bad imo.
I'm waiting for one thing to get merged (namely D3918) and then I'll make a new, probably a bit shorter example for GPUOffScreen and put it on the main gpu module page. Personally I think large examples a the one currently provided are not useful because they 1) make it look way too hard and 2) force developers to strip away a lot of code to understand what is actually required to get it working.
I agree that it would be cool to have batch_for_shader in the gpu module directly but it feels like I'm not in a position to make that decision.

About the Draw API: - I'll add more documentation for `GPUVertBuf`, `GPUVertFormat` and `GPUIndexBuf`. They are not needed in many cases though. - I have no idea what `gpu.select` is useful for. So I can't really help documenting it right now. Maybe we should just leave this module private for now. - Personally I find it a bit confusing to use the `gpu.matrix` module. It's unclear to me what I depend on when I use it. Unfortunately the module has to be used when you want to use the builtin shaders. I'd expect that Blender can derive the view/projection matrix from the context I just have to provide the model matrix. Not sure what's the best way to handle it. - Maybe `gpu.shader` could be merged with `gpu.types.GPUShader`? Ideally it would have something like this: `gpu.types.GPUShader.FromBuiltin(...)`, `shader.vertexcode`, `shader.fragcode` and `shader.geocode`. This also means that we'd have to store the source code for user defined shaders, but that would not be too bad imo. - I'm waiting for one thing to get merged (namely [D3918](https://archive.blender.org/developer/D3918)) and then I'll make a new, probably a bit shorter example for `GPUOffScreen` and put it on the main gpu module page. Personally I think large examples a the one currently provided are not useful because they 1) make it look way too hard and 2) force developers to strip away a lot of code to understand what is actually required to get it working. - I agree that it would be cool to have `batch_for_shader` in the `gpu` module directly but it feels like I'm not in a position to make that decision.

Brecht Van Lommel commented

2019-01-24 16:49:34 +01:00

Added subscribers: @ideasman42, @mont29, @BrendonMurphy, @MikeErwin, @tetha.z, @dr.sybren, @BrianSavery, @dfelinto, @jasperge-2, @StephenSwaney, @JamesCrowther, @mano-wii, @VukGardasevic, @Sergey, @Ko, @RayMairlot, @KerimBorchaev, @satishgoda1, @Januz, @bliblubli, @jta, @lvxejay, @Jeroen-Bakker, @monique, @nathanvollmer, @vitorbalbio-3, @gfxcoder, @intrah, @NumesSanguis-3, @brita, @shiprex, @snuq

MACHIN3 commented

2019-05-21 16:46:58 +02:00

Added subscriber: @MACHIN3

Brecht Van Lommel commented

2019-06-28 15:39:08 +02:00

It seems gpu.10.py is working fine, there was also a bugfix related to this recently.

It would be good if we could improve our Python API docs still, but I think everything that must be done for the release is ready now.

It seems `gpu.10.py` is working fine, there was also a bugfix related to this recently. It would be good if we could improve our Python API docs still, but I think everything that must be done for the release is ready now.

Sybren A. Stüvel commented

2019-08-09 11:00:58 +02:00

In #56351#708592, @brecht wrote:
It seems gpu.10.py is working fine, there was also a bugfix related to this recently.

This looks like an invalid module name to me. Module names are bound to the same rules as other Python names. gpu.v10.py or gpu_10.py would be valid.
Not sure in what "working fine" entails in detail, just pitching in without much context.

> In #56351#708592, @brecht wrote: > It seems `gpu.10.py` is working fine, there was also a bugfix related to this recently. This looks like an invalid module name to me. Module names are bound to the same rules as other Python names. `gpu.v10.py` or `gpu_10.py` would be valid. Not sure in what "working fine" entails in detail, just pitching in without much context.

Brecht Van Lommel commented

2019-08-13 06:16:40 +02:00

In #56351#749174, @dr.sybren wrote:
This looks like an invalid module name to me. Module names are bound to the same rules as other Python names. gpu.v10.py or gpu_10.py would be valid.
Not sure in what "working fine" entails in detail, just pitching in without much context.

These are never imported as a module so it's not a problem. It's just a naming convention for example code in the Python API docs.

> In #56351#749174, @dr.sybren wrote: > This looks like an invalid module name to me. Module names are bound to the same rules as other Python names. `gpu.v10.py` or `gpu_10.py` would be valid. > Not sure in what "working fine" entails in detail, just pitching in without much context. These are never imported as a module so it's not a problem. It's just a naming convention for example code in the Python API docs.

Brecht Van Lommel commented

2023-03-21 19:26:44 +01:00

Archiving old issue, these are either done or part of another issue.

Brecht Van Lommel closed this issue

2023-03-21 19:26:46 +01:00

Blender Bot added

and removed

labels 2023-03-21 19:26:47 +01:00