Ok, so basically an export support lib.
I'd see no harm in it if you just draft one and present as an example of
the kind of API calls you'd like to have. I think anything that the new
'export plugin API' would do, you can do in a py lib that have you for your
exporter. Then if it makes sense for
Upbge fork has object property's restored, and they are used on UPBGE in
game,
You could use this as a basis, it's kept in sync with blender master.
Upbge.org
On Thu, Mar 4, 2021, 3:46 PM Juan Linietsky via Bf-committers <
bf-committers@blender.org> wrote:
> We can probably pull request this fu
We can probably pull request this functionality into Blender ourselves, or
at least generate a detailed proposal but for this I would like to see if
Blender contributors can agree that this is something wanted and how it
would be wanted.
Best
Juan
On Thu, Mar 4, 2021 at 8:43 PM Juan Linietsky
As I mentioned before, the problem with using properties, even if hidden,
is that having this information persistent serves no purpose.
I understand that Blender can save it (with an option), but there is no
point in generating this information at any other time than saving the
exported scene..
Th
Fair points, thanks. BTW if there is an issue on the web or something for
this, am happy to study more there and maybe have extended discussions,
don't want to flood the list with learning the basics about this.
I was thinking, that if you need additional meta-data, you could maybe have
hidden cus
>
> So how is this not custom properties?
>
I don't think custom properties are the best for this use-case scenario,
for the following reasons:
* You need to generate this data *on export*. As an example, if you edited
the material nodes in Blender, you would only want to generate a target
engine
So how is this not custom properties?
https://docs.blender.org/manual/en/latest/files/data_blocks.html#custom-properties
On Thu, Mar 4, 2021 at 8:05 PM Juan Linietsky via Bf-committers <
bf-committers@blender.org> wrote:
> Hi Everyone!
>
>Most exporters are working fantastic nowadays in Blend
Hi Everyone!
Most exporters are working fantastic nowadays in Blender, so on the
Godot Engine side, we are trying to figure how better to improve our
experience to users when going back and forth between Blender and Godot.
So, this proposal consists on a very (pre-discussed) list of topics
Hi,
As part of the geometry nodes project there is a need for a spreadsheet
editor for a few use cases. However this is an editor that is not exclusive
to the nodes pipeline however and can relate to many other projects
(overrides, drivers, ...).
We did the design taking other use cases into cons
Consider `clang-tidy-diff.py` and `run-clang-tidy.py` [1] to cut down
time to run clang-tidy further. The latter is not incremental though.
Editor extensions based on clangd + LSP can show clang-tidy violations live as
the file is being edited. I've tried [2] and it's fine. There's one for VSCode
Hi, just my two cents, since I did not take part in this project in itself:
So here are some questions to the developers:
- Do you have a strong feeling about leaving a .clang-tidy file as it is
now (where file modification requires manual re-compilation) ?
I do not mind having to force clean r
Hi,
This Friday we have February's code quality day [1].
For the Clang-Tidy project we'll come up with a decision on which warnings
we still want to address and support. ANd I would really like to see the
WIP patches to be either finished or officially stated that we do not want
to address the wa
On Thu, Mar 04, 2021 at 09:52:52AM +0100, Sergey Sharybin via Bf-committers
wrote:
> - Shall we enable it by default? Maybe for `make developer` ?
If nothing else, I think that it should be on by default on our CI
builds. This way we will be able to tell when things slipped through the
cracks.
I
On Thu, 4 Mar 2021 at 09:53, Sergey Sharybin via Bf-committers <
bf-committers@blender.org> wrote:
> - Do you have a strong feeling about leaving a .clang-tidy file as it is
> now (where file modification requires manual re-compilation) ?
>
No, not really. Of course it would be nice if changes ar
Hi,
During the past months we seem to cover the majority of the warnings from
Clang-Tidy [1]. The remaining onbes either require a newer Clang-Tidy
version, or have a patch, or are a bit controversial than it originally
looked. I would say we have reached the point where we can declare the
Clang-T
15 matches
Mail list logo
