Re: [Bf-committers] Should we change the splash image when the version number changes?

[Gaia Clary]

Maybe it is as simple as displaying the splash screen in greyscale...
What about something like this:

if version_cycle == "Alpha":
  display_the_splash_in_grey_scale(saturation=0.1) #Almost black

see: http://pasteall.org/pic/show.php?id=a18beb5d36f5dfd320f091278489a294

That would be automatic.
Just a stupid thought before coffee :)
Gaia

On 10/11/2019 5:37 PM, Brecht Van Lommel wrote:

We could consider adding a new splash at the start of the release cycle,
instead of at the end. It makes some sense for a specific Blender version
to always have the same splash.

On Fri, Oct 11, 2019 at 5:29 PM Dalai Felinto  wrote:


Hi Antonio,

What you propose is not really solving the problem. To have a new
splashscreen from 2.81 and still use the 2.80 splashscreen for 2.82
(master) would be even more strange in my opinion.

In a way what we have now is no different than having a stable Blender with
a splash, and master with the same one. Which is how we did for ages,
without any major complication.

So initially the plan is to change the splash only when we enter bcon5. You
do see a different alpha/beta version in the splashscreen, and that will
have to suffice for now.

All that said, I actually believe that the true reason to change the splash
at the very last moment is because there is a lot of expectations in regard
to that. So it is nice to align the hype of the splash reveal with the
release of a new version of Blender.

Regards,
Dalai

--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com


Em sex, 11 de out de 2019 às 10:44, antonioya blend 
escreveu:


Hi all,

Until now, when we had a version, the splash was changed at the end when
the release was made. With the new way of working, the version is changed
at the beginning and appears in the splash, and we follow the development
in the master branch. The release of the previous one has its own branch
(blender-v2.81-release).

If we decide that master is the new version (in this case 2.82), the
logical thing would be to change the splash at the same time that the
version change is made, so the developing version would have a different
splash. Now it is very strange to have a different version in the splash,
but with the same image from the previous version. Perhaps that splash
could be the definitive of 2.82 or something more generic like the one we
used during the development of 2.80.

This is just an idea that I wanted to share with you to see the different
opinions. Anyway, if you think it is not necessary, forget it.

Regards,
Antonio Vazquez
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Update openCollada to 1.6.68

[Gaia Clary]

Hi, Platform maintainers :)

Please update the subversion repository libraries to OpenCollada 1.6-68
This allows us to add support for importing Animation clips.

The Release sources recommended by OpenCollada can be found here:

https://s3-us-west-2.amazonaws.com/opencollada-promotion-artifacts/OpenCOLLADA_v1.6.68.zip

Or if you prefer to go with the git repository, the tagged revision is here:

   https://github.com/KhronosGroup/OpenCOLLADA/tree/v1.6.68

The git hash is 6031fa956e1da4bbdd910af3a8f9e924ef0fca7a

Please tell me if anything around the library build needs improvement. I 
then will forward this to the opencollada people :)


cheers,
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Euler angles clarification

[Gaia Clary]

How exactly do you test with collada files exported by blender?
Can you explain this in some more detail?

Sidenote: The Collada exporter uses the decomposition of the
transformation matrix and extracts  the euler rotation with

    mat4_decompose(loc, q, size, matrix);
    quat_to_eul(rot, q); /* XYZ order */

i am not sure though if this helps.

- gaia


On 25.03.2018 13:34, Recep Aslantas wrote:

Hi,

Which rotation conventions does Blender use for Euler rotations (XYZ, YXZ...)?
Intrinsics rotations or extrinsic rotations?

Since I'm testing the math with COLLADA files which exported by Blender.
I don't know what exactly XYZ means in Blender.

Thanks for clarification

- R
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Commit logs

[Gaia Clary]

Thanks for this link! I didn't know this guideline before. I follow it now.

cheers,
Gaia

On 28.02.2018 19:55, Brecht Van Lommel wrote:

Hey everyone,

As a reminder for all committers, please follow the commit log rules here:
https://wiki.blender.org/index.php/Dev:Doc/New_Committer_Info#Commit_Logs

Unclear and inconsistent commit logs make it harder for other developers to
understand what you are doing or to trace back changes in git history. A
good commit description also makes writing docs and release notes faster.

Thanks,
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.79a Release Candidate AHOY (rB78a77fe622b8)

[Gaia Clary]

Sorry for the noise. I thought i messed up something but actually all is 
well.

Although the story behind it is a bit odd:

The breakage actually happened with commit 6febe6e72 which was labelled 
"Silence warning from Collada". The commit slipped through my attention 
(my fault) so i was not aware of it and so i did not report it to be 
added to 2.79a. But even when i had looked at the git show 6febe6e72 i 
would have considered this a very innocent change. You only can see the 
mess when you look at the sources in this case.


Well, the good news is the breaking commit did not arrive at the 2.79a 
branch, i found it in master and fixed it also in blender2.8 and all is 
well now :)


cheers,
Gaia


On 02.02.2018 10:36, Bastien Montagne wrote:
Eh… for some reason, we don't have same code in 2.79a and master 
for DocumentWriter.cpp, and that issue is not present in 2.79a afaict. 
Would be nice if you could double-check that though. But 
rB78a77fe622b8 does not apply cleanly and is not needed on 2.79a imho.


Bastien


Le 02/02/2018 à 01:03, Gaia Clary a écrit :
i found a nasty mistake in one of my recent fixes where i have 
unintentionally commented out 2 lines which now disable Collada 
animation export. Please can you consider to add this fix to 2.79a?


rB78a77fe622b8 -- fix: unintentionally commented out collada 
animation export


thanks,
Gaia


On 23.01.2018 12:41, Sergey Sharybin wrote:

Hi everyone,

A huge work was done to port crucial fixes (and even more!), and we are
ready for 2.79a Release Candidate now.

Yes, that's right. There are so much things that changed, that we do an
extra steps for corrective release, something we didn't do before.

Full list of changes can be found there:
https://developer.blender.org/T53683
We will work on a better release page shortly.

Information for platform maintainers:

- Build from the blender-2.79a-release branch,
SHA 61335d853d113c827a54ab3b71e357fab2aa507a
- Addons revision: cf60d1ad47622f85d8294609198de482fb8c4f22
- Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
- Libraries SVN tag: blender-2.79a-release

Suggested name: blender-2.79a-rc-

Make sure you're using 2.79a tag for libraries.

Put builds to usual location and let me know when they are ready.,

Special thanks to Bastien Montagne for coordinating 2.79a, and everyone
else who invested their time on porting fixes to the branch!



___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers



___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.79a Release Candidate AHOY

[Gaia Clary]

i found a nasty mistake in one of my recent fixes where i have 
unintentionally commented out 2 lines which now disable Collada 
animation export. Please can you consider to add this fix to 2.79a?


rB78a77fe622b8 -- fix: unintentionally commented out collada animation 
export


thanks,
Gaia


On 23.01.2018 12:41, Sergey Sharybin wrote:

Hi everyone,

A huge work was done to port crucial fixes (and even more!), and we are
ready for 2.79a Release Candidate now.

Yes, that's right. There are so much things that changed, that we do an
extra steps for corrective release, something we didn't do before.

Full list of changes can be found there:
https://developer.blender.org/T53683
We will work on a better release page shortly.

Information for platform maintainers:

- Build from the blender-2.79a-release branch,
SHA 61335d853d113c827a54ab3b71e357fab2aa507a
- Addons revision: cf60d1ad47622f85d8294609198de482fb8c4f22
- Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
- Libraries SVN tag: blender-2.79a-release

Suggested name: blender-2.79a-rc-

Make sure you're using 2.79a tag for libraries.

Put builds to usual location and let me know when they are ready.,

Special thanks to Bastien Montagne for coordinating 2.79a, and everyone
else who invested their time on porting fixes to the branch!



___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] How to maintain for master and blender2.8 in parallel?

[Gaia Clary]

Hi;

I would like to apply a few fixes to the master branch and to the 
blender2.8 branch in parallel. But i do not know a good way to apply 
those fixes in a correct way. Is there a general workflow for this?


I thought of fixing in master, then cherry-pick the commits to 
blender2.8 Is that the right way to go? Or do i just do my fixes in 
master and blender2.8 separately? Or is there yet another way to do it?


Please can i get an advise?

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Propose to update collada libraries to v1.6.62 (not urgent)

[Gaia Clary]

Hi;

I propose to update the openCollada libraries to

https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.62

This update fixes the "invalid utf-8 characters in comments" warnings 
when building with Collada. As far as i read in the last 32 commits 
since our last update, there are no functional changes.


For whoever builds the libraries, i collected some tips from the past:

- Some cmake variables need to be adjusted
  to make the libraries work with Blender (see below)
- The Install prefix you apparently must adjust to your needs.
- Also please use '/' as path separator, even when you are
  on Windows,otherwise the build will fail.
- As far as i can see you can generate directly into the
  subversion folders, the generated files should be ready
  for checkin without any manual changes.*
- *You might see an error related to building the
  Framework Validator when you build the Debug libraries.
  This error can be ignored, because the validator is not
  needed for building Blender.
- I used visual studio to build the INSTALL target.

The list of adjusted CMAKE variables is here:

CMAKE_INSTALL_PREFIX = D:/lib/win64_vc12/opencollada (see below)
CMAKE_DEBUG_POSTFIX = _d
CMAKE_CXX_FLAGS_DEBUG = /MTd /Zi /Ob0 /Od /RTC1
CMAKE_CXX_FLAGS_RELEASE  = /MT /O2 /Ob2 /D NDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO = /MT /Zi /O2 /Ob1 /D NDEBUG
CMAKE_CXX_FLAGS_MINSIZEREL = /MT /O1 /Ob1 /D NDEBUG
CMAKE_C_FLAGS_DEBUG = /MTd /Zi /Ob0 /Od /RTC1
CMAKE_C_FLAGS_RELEASE = /MT /O2 /Ob2 /D NDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO = /MT /Zi /O2 /Ob1 /D NDEBUG
CMAKE_C_FLAGS_MINSIZEREL = /MT /O1 /Ob1 /D NDEBUG

Please let me know if anything is annoying with the build.Then i try my 
best to talk the collada people into fixing it :)


cheers,
Gaia


**
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.79a release - proposed list of commits

[Gaia Clary]

Maybe we can add

https://developer.blender.org/rB26f98446b17f418a633a1420a491e5ad0b59b988

I do not know if this change breaks anything. At least i am not aware of 
issues for now. If it really breaks something then users can report. 
Also in case of failure the workaround is simple: The user can set the 
export option manually in the export panel instead of relying on Blender 
to decide what is correct and what not.


cheers,
Gaia


On 03.01.2018 12:36, Bastien Montagne wrote:
For the record, created a phab task to track the release status 
(thanks to Campbell for the suggestion): 
https://developer.blender.org/T53683



Le 27/12/2017 à 12:05, Bastien Montagne a écrit :
So… looks like our list of commits to backport is too long, even the 
ML server does not want to swallow it. :)


Here is the list we gathered, Sergey and I: http://pasteall.org/737326

First part are commits we think should be included, please 
double-check yours though.


Second part are commits we should rather not backport, though they 
might be considered. Please check them to see if you really want to 
include some.


You may also suggest other commit of course, just keep in mind that 
we want only fixes, preferably not complex ones unless they address 
some critical issue. Enhancements or new features are only possible 
if they are really dead simple code wise.


Thanks and happy Christmas,
Bastien

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.79a release - proposed list of commits

[Gaia Clary]

hi.

I believe this one (Collada - crash during export) should be added: 
rB1f95347882 ( Fix T53322 ) But maybe Campbell should decide.


cheers,
Gaia

On 27.12.2017 12:05, Bastien Montagne wrote:
So… looks like our list of commits to backport is too long, even the 
ML server does not want to swallow it. :)


Here is the list we gathered, Sergey and I: http://pasteall.org/737326

First part are commits we think should be included, please 
double-check yours though.


Second part are commits we should rather not backport, though they 
might be considered. Please check them to see if you really want to 
include some.


You may also suggest other commit of course, just keep in mind that we 
want only fixes, preferably not complex ones unless they address some 
critical issue. Enhancements or new features are only possible if they 
are really dead simple code wise.


Thanks and happy Christmas,
Bastien

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please merge your master work in blender2.8 immediately

[Gaia Clary]

Hi, Bastien;

I have been trying to do the requested merge but i failed to understand 
how to do it.
I followed advise from IRC and documentation from git and i ended up 
doing this:

git checkout master
git fetch
git pull --rebase
git checkout blender2.8
git merge master

This did not merge my most recent commits from master to blender2.8. So 
after
trying out a lot of things to fix that, i finally deleted the git 
repository from my
computer and cloned it again according to the documentation here:

 https://wiki.blender.org/index.php/Dev:Doc/Tools/Git

Then i tried again to merge master into blender2.8
However all my recent changes in master still do not
show up in blender2.8 regardless what i try.

I am sure that i overlook something very basic here, but i just can not
figure out what the problem is. I know i am supposed to know how to
work with git. But please can you give me a tip how to proceed as i am
totally stuck :(

thanks a lot,
cheers,
Gaia


On 03.07.2017 16:37, Bastien Montagne wrote:
> This is a reminder to all developers : when you commit something in
> master, that goes beyond the oneliner and has even a remote possibility
> of creating a conflict with blender2.8 branch, please handle the merge
> in that branch immediately yourself. Can save a lot of time for someone
> else to figure out what is the issue, what work was done in both
> branches, and how to solve the conflicts.
>
> This could be simplified to: always merge master in blender2.8 after you
> did some commit there.
>
> Also, related: DO NOT make 'cleanup' things like adding/removing spaces
> or blank lines in blender2.8, unless you are rewriting the whole piece
> of code! This can easily create stupid virtual conflicts later. If you
> want to do style or cosmetic cleanup, do it in master, merge in
> blender2.8, and everyone is happy.
>
> Thanks,
> Bastien
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Whoever is interested in Collada: Request for testing

[Gaia Clary]

Hi, all

I have added a change to the Collada exporter that is supposed
to fix https://developer.blender.org/T51288

the fix introduces one behavioral change. That is:
Mesh objects can now be exported

- without any textures (no materials)
- only with UV Textures (exported as Materials)
- only with materials (no uv textures)

Previously it was possible to export material textures and UV textures
in one go. But that caused very odd material definitions which get
wrong when multiple objects are involved when they share materials.

If you rely on the Collada exporter then please can you check if it still
works for your special case? I have committed the changes to master,
so the next daily build should contain the modifications.

sidenote: When you export UV textures and later reimport the dae to
Blender then you should see your objects no longer have UV textures,
but equivalent materials assigned.

Any hint for change or improvement is very welcome!
Thanks a lot!

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada test files. How to organize, where to place?

[Gaia Clary]

Ok, bzzt_ploink pointed me to a better location:

https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/collada/...

Is it ok to begin adding testfiles there?

-gaia-

On 18.06.2017 21:01, Gaia Clary wrote:
> 2.) Where is a good place to setup such a test collection?
>   I guess this is good? :
>
>   blender/tests/collada/...
>
>   But maybe there is a better place?

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada test files. How to organize, where to place?

[Gaia Clary]

Hi;

I am creating some blend files for testing the Collada exporter
and Importer. I want to add a bit of python scripting so that
Blender can be called from a shell script, open a test blend file,
execute some activitieslike exporting some items, import them
back and do some checks.

Now i have questions:

1.) How can those blend files be used for some sort of automatic
 testing to ensure during building Blender that the module
 creates consistent results? I know there is some test environment
 but i am still a bitunsure how to work with it.

2.) Where is a good place to setup such a test collection?
 I guess this is good? :

 blender/tests/collada/...

 But maybe there is a better place?

3.) Alsoif there is any demo for how to setup a blend file for
 testingpurposes, please can you point me there? I thought i
 had found something a while back but i no longer can find it.

Thanks for any tip and advise on that :)

Cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Update to OpenCollada 1.6.51

[Gaia Clary]

Dear Platform maintainers

2 days ago Jens Verwiebe has found an issue with building Blender
on Linux with Clang. It was due to an error in one of the
Collada include files. The issue has already been fixed in a
subsequent OpenCollada release.

Because of this i propose to update to OpenCollada - 1.6.51:

https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.51

or if that suits better, use the commit number:

  0c2cdc17c22cf42050e4d42154bed2176363549c

The OpenCollada commits can be found here:

  https://github.com/KhronosGroup/OpenCOLLADA/commits/master

Please be so kind and report any remaining issues with building the 
libraries or building blender with the libraries. If you know a fix
for your find, you either can forward the fix to OpenCollada project
or tell me about it. Then i will take care :)

thanks,
cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal for a small UI improvement for driver setup

[Gaia Clary]

About the separate mini-python: I like that idea. As far as i can
see this would work well. For our own purposes this would be a
brilliant solution.

Regarding the short term improvement:

We already get asked to either "reload trusted" or "ignore"
from within the top Menu bar as soon as drivers are trying
to get to work. This entry does not go away until we hit
one of those 2 options.

The only 2 problems that i have with this approach are:

- when you have no blend file, then you can not reload.
   In that case you only get the "ignore" option which is
   not very helpful here.
- When you forget to save before Reload, then your
   most recent work will be silently dropped.

So what about the following idea? :

We keep the switch in the  menu bar.
But instead of "Reload" we do:

[ "Store" | "Ignore" ]

And we could  open the file selection window so the user has the
option to either store to a different file or create a new file
when there is none yet.If that is inconvenient, then maybe this
may be a somewhat more elaboratealternative:

- With existing Blend file : [Store | Reload as | Ignore]
- Without Blend file:[Reload as | Ignore]

In that solution the user gets the file selection box only for
the "Reload as" option.

This approach would be more convenient and avoid the spreading of
property fields all over blender.

gaia

On 04.06.2017 13:58, Joshua Leung wrote:
> Hi,
>
> I agree that the current situation isn't great, and does need to be
> improved.
>
> However, IMO the proposed solution is not good either. Specifically, as
> presented, it does seem that to imply that that checkbox will always get
> shown. There are several issues with this:
> 1) It is highly unlikely that you will want to disable the thing again once
> enabled.
> 2) That setting applies to all scripts/settings, not just the current
> driver. It is therefore misleading to include it as a checkbox there.
> 3) When loading existing files (with the autorun setting disabled), there's
> the duplication that Sergey mentioned (i.e. info header + this panel).
> 4) IIRC, just putting the checkbox there isn't enough to get everything
> running properly for the current session only.
>
> ---
>
> That said, when this autorun setting is disabled (via userpref or
> commandline options), there *is* the annoying problem that newly created
> drivers cannot be run, with no obvious way to get them working. This is a
> usability issue.
>
> As a short-term compromise, I propose that beside/under the error prompt,
> we include the "Reload Trusted" operator button (shown in the info header
> when loading files when autorun is disabled). We'd have to prompt the user
> to save their work (or do it for them), and perhaps the label would need to
> be different (something like "Enable Python autorun").
>
> --
>
> In the long-term though, IMO we really should look into building our own
> little "mini-Python interpreter" for interpreting driver expressions.
> Campbell's work with sandboxing the Py interpreter (e.g. by whitelisting
> bytecode opcodes) is a promising if fragile approach. However, it doesn't
> mitigate the multithreading problems with Python and the GIL (i.e. there
> can only be a single Py interpreter instance running/evaluating code at
> one). I know that Bassam and a few other riggers have been having problems
> with some of their rigs running slowly (or even crashing) under the new
> depsgraph due to multiple pydrivers getting scheduled to run at once, and
> everything grinding to a halt as they're evaluated one by one. Thus, by
> building our own "driver expression interpreter" that only handles the
> subset of Python-like syntax actually needed to evaluate driver
> expressions, we can solve both security + performance issues at once.
>
> As a fallback, "full" Python evaluation can still occur if our interpreter
> cannot handle a particular expression (i.e. the rigger tried to access a
> custom function, or tried to do something "fancy" with indexing/attribute
> access). That then would still required autorun to be enabled, and would
> still be subject to the GIL restrictions. However, since fewer drivers
> should now be affected by the Py bottleneck/limitation, it's still a net
> positive for users in general over the current situation.
>
> Regards,
> Joshua
>
>
>
>
>
> On Sun, Jun 4, 2017 at 11:06 PM, Gaia Clary <gaia.cl...@machinimatrix.org>
> wrote:
>
>> The current solution to this situation is also not a good idea i believe :)
>>
>> However, isn't there a difference here between ?
>>
>> - a global definition in user preferences
>> - a session related setting
>&

Re: [Bf-committers] proposal for a small UI improvement for driver setup

[Gaia Clary]

The current solution to this situation is also not a good idea i believe :)

However, isn't there a difference here between ?

- a global definition in user preferences
- a session related setting

In that sense i believe my proposal is not that bad, as it allows to
set the autorun option right on spot (where the drivers are defined)
but only for the current session. And it avoids the display of an error
and it seemsvery intuitive to me.

Also i believe when there is a bad idea at all here, then it is to force
the user to enable scripting when all they want is to use drivers.
Of course i know Campbell has put some effort into this to see how python
could be made more secure so that using it within drivers would no longer
be a security problem, and "python in drivers" could be always enabled.
But as far as  i know there is no satisfying solution for this,
so drivers still need to have auto run enabled.

Anyways, it was just a proposal, if its not useful, then its ok for me.
I asked at least :)

cheers,
Gaia

On 04.06.2017 10:26, Sergey Sharybin wrote:
> Hi,
>
> This isn't a good idea. You should not expose same user setting all over
> the interface. All those settings should be kept in a centralized place.
>
> On Sun, Jun 4, 2017 at 1:04 AM, Aaron Carlisle <carlisle@gmail.com>
> wrote:
>
>> I think it is a good idea, I also think that it would be fine to have this
>> in 2.79.
>>
>> Aaron Carlisle
>>
>> Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist
>> Project administrator for the Blender 3D Documentation Project
>>
>> On Sat, Jun 3, 2017 at 1:04 PM, Gaia Clary <gaia.cl...@machinimatrix.org>
>> wrote:
>>
>>> Hi;
>>>
>>> Assume you have disabled "Autorun Python Scripts" by default.
>>> Now add a new driver and step into the graph editor to edit
>>> the Driver python expression.
>>>
>>> Currently you will see an error text in the panel.
>>> But what about a change like in the image here:
>>>
>>>   http://pasteall.org/pic/show.php?id=116080
>>>
>>> If this is an acceptable improvement, is that something that
>>> could possibly already go into Blender 2.79 or would that be only
>>> good for Blender 2.8 ?
>>>
>>> cheers,
>>> Gaia
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] proposal for a small UI improvement for driver setup

[Gaia Clary]

Hi;

Assume you have disabled "Autorun Python Scripts" by default.
Now add a new driver and step into the graph editor to edit
the Driver python expression.

Currently you will see an error text in the panel.
But what about a change like in the image here:

 http://pasteall.org/pic/show.php?id=116080

If this is an acceptable improvement, is that something that
could possibly already go into Blender 2.79 or would that be only
good for Blender 2.8 ?

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Update to OpenCollada 1.6.47

[Gaia Clary]

Dear Platform maintainers

Recently i have posted 2 change requests to the openCollada project:

* Fixing the scons build on linux (requested by Hackerman)
* Improved error handling (reporting errors instead of terminating Blender)

Both changes have been accepted and are available now in the OpenCollada 
repository.
Note: The last time we updated OpenCollada in Blender was about 2 years ago.

Because of this i propose to update to OpenCollada - 1.6.47:

https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.47

or if that suits better, use the commit number:

 22b1f4ff026881b4d2804d397730286ab7e3d090

from here:

 https://github.com/KhronosGroup/OpenCOLLADA/commits/master

Please be so kind and report any remaining issues with building the 
libraries.
If you know a fix for your find, you can forward the fix to OpenCollada
project or tell me about it. Then i will take care :)

thanks,
cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] not able to build environment

[Gaia Clary]

Hi;

I have added a few lines to the wiki page so it may become
more clear what you have to install and why you need to
install it. I hope that helps a bit:

https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake


On 05.11.2016 15:04, Nishant Varshney wrote:
> Sir the link which you have provided 
> https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake
> Has git, subversion,  cmake and visual studio.. Here out of all I have to 
> choose one or I have to install everything.. Like sub version  then git then 
> cmake then Cuda?
>
>
>Original Message
> From: nishant26varsh...@gmail.com
> Sent: November 5, 2016 7:28 PM
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] not able to build environment
>
> Earlier I was trying the python using tortoise svn where I got that error now 
> you have given me visual studio's steps I will try that!
>
> Thanks!
>
>
>
>Original Message
> From: brechtvanlom...@pandora.be
> Sent: November 5, 2016 7:16 PM
> To: bf-committers@blender.org
> Reply-to: bf-committers@blender.org
> Subject: Re: [Bf-committers] not able to build environment
>
> The instructions for building Blender with Visual Studio are here:
> https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake
>
> The error you get earlier was from trying to download the Blender
> Documentation, for which the instructions are here (but will not work
> right now because of the corruption, which I guess will be solved
> within the next few days):
> https://www.blender.org/manual/about/contribute/install/windows.html
>
> It's not clear to me which one you're trying to build..
>
> On Sat, Nov 5, 2016 at 2:37 PM, Nishant Varshney
>  wrote:
>> Can you please tell me steps through  which I can build and use visual 
>> studio as my programming environment!  Because I wanted to use visual studio 
>> but the steps on the blender site were not for visual studio they were of 
>> command prompt by downloading libraries via svn
>>
>> Original Message
>> From: martijn.ber...@gmail.com
>> Sent: November 5, 2016 6:55 PM
>> To: bf-committers@blender.org
>> Reply-to: bf-committers@blender.org
>> Subject: Re: [Bf-committers] not able to build environment
>>
>> I can host a dump of the svn it works again.
>>
>> Do you want the windows x64 visual studio 2013 binaries ?
>>
>> Martijn
>>
>> On Sat, Nov 5, 2016 at 1:34 PM, Nishant Varshney <
>> nishant26varsh...@gmail.com> wrote:
>>
>>> How long will it take sir..because I am not able to build the environment
>>> and unable to contribute
>>>
>>>
>>> Original Message
>>> From: brechtvanlom...@pandora.be
>>> Sent: November 5, 2016 5:56 PM
>>> To: bf-committers@blender.org
>>> Reply-to: bf-committers@blender.org
>>> Subject: Re: [Bf-committers] not able to build environment
>>>
>>> It seems it's the repository that got corrupted, someone will need to
>>> fix it before you can download it:
>>> https://developer.blender.org/T49777
>>>
>>> On Sat, Nov 5, 2016 at 12:51 PM, Nishant Varshney
>>>  wrote:
 hello sir
 sorry for the incomplete information.

 i had attached a picture earlier in my mail of the xml error that i had
 faced.

 I am having an ASUS laptop.
 windows 10 pro,version 1607,build 14393.
 ram = 8gb
 processor = i7
 graphic card = nvidia gtx 950m

 the xml error i face when i was building environment by following this
>>> page
" https://www.blender.org/manual/about/contribute/install/windows.html
>>> "
 and while downloading the manual in folder c:\ blender_docs using
>>> tortoise
 svn .

 " THE XML RESPONSE CONTAINS AN INVALID XML"
 " MALFORMED XML: NO ELEMENT FOUND" .

 On Sat, Nov 5, 2016 at 4:14 PM, Piotr Arlukowicz <
 pio...@polskikursblendera.pl> wrote:

> Hey, Nishant,
> just a quick note: if you want some help, be so nice and provice more
> information, at least what computer you have, what windows, describe
>>> step
> by step your actions and at least provide the XML error you've got. This
> way you help us to help you.
>
> And there is also a page for bugreports, which are RECOMMENDED way of
> submittings bugs like this.
>
> Bug can be reported here: https://developer.blender.org/
>
> best regards
> Piotr
> Arlukowicz, BFCT
>
> *YT: /user/piotao?feature=guide*
>*FB:* */polskikursblendera* *TW:*
> */piotao*
> *Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz
> *
> *Polski Kurs Blendera:* http://polskikursblendera.pl
>
>
>
>
>
> 2016-11-05 6:59 GMT+01:00 Nishant Varshney > i am not able to build the environment in my windows pc help please
>>
>> when i install tortoise and do svn check out it fails with an error 

Re: [Bf-committers] COLLADA Node Transform

[Gaia Clary]

Hi;
thanks for this information.
Would you mind to create a report for this?

Here is the link:

https://developer.blender.org/maniphest/task/edit/form/1/

You also can assign me to the report.
thanks
gaia

On 03.11.2016 08:59, Recep Aslantas wrote:
> I've another issue about node transform, since the subject is same I'm 
> writing here
>
> I think Blender exports COLLADA matrix incorrectly in some cases
> maybe it is related OpenCOLLADA directly I don't know yet
>
> I created a scene with a sphere and cube, then I scaled cube (ScaleY) a bit
> then I added sphere as child of cube, everythings looks normal in Blender
> So cube is scaled and sphere is not and sphere model matrix must be ID Matrix 
> in World (I think)
>
> Then I exported as COLLADA, It seems that  Blender exported sphere matrix 
> incorrectly
> I was not sure and test in other tools the exported file
>
> The exported Node looks like:
>
> Cube Matrix:
>
> -0.8466222 -0.507823  0.4833452 0
> -0.4927458  1.530348 -0.5537914 0
> -0.2010783 -1.612002 -0.6780063 0
> 0  001
>
>
> Sphere Matrix:
>
> -0.8466221  -0.4927458 -0.2010783 0
> -0.09768837 0.2943883 -0.3100958 0
> 0.4833452   -0.5537914 -0.6780063 0
> 0   0  01
>
> If the sphere must be Identiy (in World) then Sphere matrix must be inverse 
> of Cube (in Local) in scene-graph
> am I right?
>
> After imported the COLLADA file, Blender renders same as I did and different 
> from original,
> but Apple Quicklook still render correctly, weird! modo, FBX Review, tree.js 
> renders like my result
>
> I'm sharing .blend, .dae and some screenshots via Dropbox:
>
> https://www.dropbox.com/sh/9nwr0t9j6e7rj1o/AACPnQ3m-OEq9amNemxZ6TcHa?dl=0
>
> Recep
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] COLLADA Node Transform

[Gaia Clary]

The 'Both' option was made especially for fixing a (blender unrelated) 
issue with an Importer from another target system. But this issue has 
already been fixed long time ago. I just forgot to remove the option 
from the Blender exporter, thanks for the reminder!

gaia


On 02.11.2016 12:11, Recep Aslantas wrote:
> Hello,
>
> With 'Both' option Apple Quicklook/Preview also renders incorrectly, probably 
> applying same transform twice
>
> Any ideas?
>
>
> Thanks
>
> - Recep Aslantas
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] About the Default Behavior of Dissolve Edges

[Gaia Clary]

Hi;

I sort of expect that the default behavior of dissolve edges (X - 
Dissolve) is to only dissolve edges, but apparently this is not the 
case, see:

http://pasteall.org/pic/show.php?id=107839

Doesn't it make much more sense here to change the default for the 
Dissolve Verts operator option to 'unchecked'?

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Revisions for the final 2.78

[Gaia Clary]

If possible please also add the following 3 fixes for Collada:

4b891b40c218ef5f45706cbc4636a5333469dd1c

 Fix for an issue with the new Blender collada profile.
 Tested with Linux Build Bot:
https://builder.blender.org/builders/linux_glibc219_x86_64_cmake/builds/289

7a259d8422b9fd29fb9990269821fa64fc146a01

 Fixes Linux compiler warnings regarding the collada module.
 Tested with Linux Build Bot:
https://builder.blender.org/builders/linux_glibc219_x86_64_cmake/builds/290)

36d0ea3123743e675333e90c712c69d666fe5710

 Fixes another Linux compiler warning (sorry, amend did not work 
after push)
 Tested with Linux Build Bot:
https://builder.blender.org/builders/linux_glibc219_x86_64_cmake/builds/291

@whoever uses Collada:

Please could you do a quick check if the commit 4b891b40 works for you?
Export rigged model -> import back rigged model
The imported skeleton should look similar to the exported skeleton (bone 
lengths).

thanks,
Gaia


On 22.09.2016 12:39, Sergey Sharybin wrote:
> Hi,
>
> We are working on getting 2.78 finally released.
>
> here are the lists of revisions ported to the branch since Release
> Candidate 2.
>
> Blender:
>
> 3b6ce41 Fix memory leak in copy pose operator
> 804f6bf fix Mac build with Xcode 8
> fe28e35 Fix T49179: Parts of mesh disappear with adaptive subdivision
> e007552 Fix Py's IDs user mapping: do not consider proxy_from here.
> a2a5ae5 Fix Py's IDs user mapping: do not consider ShapeKeys' from here.
> a8ed914 Fix crash in some cases when deleting particle systems.
> ddbbcbb Fix filebrowser not getting back to valid dir in Release builds.
> 4b046c5 Fix T49372: Fresnel node: difference between 2.76 and 2.78 GLSL
> output
> 0552d58 Fix T49384: crash in tangent space calculation with NaN mesh
> vertices.
> 6c28d3b Fix T49245: Adaptive Subdivision with Auto Smooth causes weird mesh
> appearance
> 772dab9 Cycles: Fix typo that would sometimes result in subsurf modifier
> being disabled
> 76b CacheFile: make sure SpinLock is destroyed when exiting Blender.
> cc9d0ef Lowercase includes for psapi.h and dbghelp.h windows includes. This
> makes cross compilation a little less painful
> 1f5cd85 Fix T49375: align rotation with snap target isn't toggleable in
> edit mode.
> f2da63c Fix T49386: Blender crashes when told to load an OCIO LUT that does
> not exist
> 2382d1c regression fix for 1346482d23f167fa57049128384246397fda8d27: The
> length of leaf bones should always be set to the length of the smallest
> bone. since the mentioned commit the importer did only recalculate the leaf
> bone length when the 'fix leaf bones' option was also enabled.
> 0b9cfbf GPencil D+W Pie: Don't show editing operators when not in editmode
> 586c589 Fix: Grease Pencil sculpting crashes when sculpting on layers
> without any strokes
> c77da24 Fix non-finite normalization factor in certain cases
> f339d5a [windows] add some helpers to make.bat to facilitate making release
> builds.
> 42c17cb Bring blender_release.cmake uptodate with the changes from D2227
> f915ee8 CMake: Fix copy-paste error
> 8f28441 Cycles: Adaptive isolation
> 940f360 Cycles: Fix update of subdivision meshes when global dice rates
> change
> 7994548 Cycles: Soft minimum for dice rates
>
> Addons:
>
> b9c3f23 Urgent fix: T49403 Fix for broken change tab category feature: user
> preferences save was broken
> 0872705 Manual Reference: add links for object tab
> 959f9d2 Fix T49357: OBJ importer cannot deal with texture names with spaces.
> 510cd44 Use relative import
> 5b7b6a5 Referance Manual: Fix links
>

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] collada fixes

[Gaia Clary]

Hi;

Here is a fix for Collada:

The Collada Importer did not import the Blender Profile information
correctly when multiple objects are bound to the same armature.
This caused Bone tails to be placed wrong.
I also tried to remove some warnings from the Linux compiler.

All together i made 3 commits:

4b891b40c218ef5f45706cbc4636a5333469dd1c (the main fix)
7a259d8422b9fd29fb9990269821fa64fc146a01  (attempt to silence warnings)
36d0ea3123743e675333e90c712c69d666fe5710 (2nd attempt to silence warnings)

If this is still possible then please can you add those fixes to the 
release?
Maybe also someone can take a look into the fixes to double check that
all is ok.

For testing:

- Create a rig with multiple Mesh Objects bound to it.
- Export the rig and the Meshes with "Use Blender profile" enabled
- Import the file back to Blender and verify that all bones and meshes
   are imported correctly (same size, same location)

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Should i fix a Collada bug or not ?

[Gaia Clary]

Hi;
 From IRC i got the advise to ask in this mailinglist:

i have extended the blender Collada profile to better support the 
transfer of bone tails, bone roll, and bone layers. A few days ago i 
realized that the default behavior of the Collada importer has changed 
and i fixed that for 2.78. However this fix uncovered another issue 
where the Collada Importer does not use the bone tail information in a 
consistent way when multiple meshes are skinned to the same armature. 
This causes the Collada importer to behave more or less like it behaved 
in 2.77

My question is: Should i fix this for release 2.78 (my favorite choice, 
this should be doable in one day), or should i wait after the release is 
out?

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Please can you add 1346482d23f167fa57049128384246397fda8d27 to the release 2.78?

[Gaia Clary]

This is a regression fix for the Collada importer:

The importer used to set the length of the last bone in a chain to the 
length of the smallest bone in the armature. This was the best 
alternative to get around the problem that collada only knows joints but 
not bones. During recent development this feature got broken (soprry, i 
did that) and since the breakage happened the collada importer set the 
length of the last bone in a chain to 1 Blender unit.

The commit 1346482d23f167fa57049128384246397fda8d27 fixes this and make 
the importer again set the bone length of the leaf bones as before.

cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Stepping away from Blender development

[Gaia Clary]

Hi, Campbell;

Thanks for all the time you have put into helping me to get
started with programming in Blender. Without your guidance
i fear that i wouldn't have been able to find my way through
all of this!

Anyways i wish you a good time and much fun with exploring
new horizons. All the best,
gaia


On 01.08.2016 14:50, Campbell Barton wrote:
> Hi, writing this mail to say that I'll be taking time away from
> Blender development,
> I'm stepping down as maintainer/module owner.
>
> I'll be taking an extended period of time off, to work on my own
> projects for a while, explore new horizons!
>
> It's been an honour to work on the open projects with talented artists
> & developers.
> All the best,
>

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Issues with broken Addons on windows

[Gaia Clary]

Hi;

*Question:*

Can we tell our Addon to only search in the Blender Python
System folders to become independent from what other
addons add to the Scripts folders?

*Why we want that:*

We get frequent (~twice per week) Addon installation error reports
from our Windows users:

 %1 is not a valid Win32 application

We debugged this and found the cause is a file _socket.pyd in the
scripts directory:

C:\Users\\AppData\Roaming\Blender 
Foundation\Blender\2.76\scripts\_socket.pyd

Addons seem to lookup the scripts folder for pyd files and take
what they can find there, even if the same file is delivered with
Blender's own python.

*Remark:*

We can not find out how this _socket.pyd file gets into the
scripts folder. We for sure do not distribute this.

Also all users reported so far that they use the Addon Installer
to install their addons and that's it.

The "fix" is: delete the application data folder, restart blender
and all is  well. IMHO this is not a fix but an odd workaround.

Thanks for taking care :)
cheers,
Gaia
||

||

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] The future of FBX and/or other formats in Blender

[Gaia Clary]

Have our attempts to improve the Collada module really been such a desaster?
I try to not take the personally. Anyways, i tried to contact you for 
testing your
exporter:

 https://developer.blender.org/T41071

It seems like you overlooked that.

And just one more note about an import/export module:
The challenge is not the exporter but the Importer.
And i am almost sure this is true for FBX and for Collada equally.

cheers,
Gaia

On 10.02.2016 21:41, Juan Linietsky wrote:
> Guys I'm sorry. I've seen this situation happening over and over to no end
> for more than a decade.
> How about some self-criticism from Blender instead of blaming Autodesk?
>
> If you guys really had cared about open standards and getting along well
> with game engines, you would have done the following:
>
> 1) Make sure you export proper Collada. The specification is pretty clear.
> 2) Push game engines to fix their importers.
>
> Blender support for Collada has always been a disaster. There was never any
> will to fix it.
>
> -I originally insisted against using OpenCollada due to the huge binary
> bloat, and the fact the spec is pretty simple.  You guys wanted to go with
> it.
> -The exporter was huge and full of bugs. I insisted that a lot of features
> missing in the spec needed to be implemented, was ignored.
> -Meanwhile, all the missing Collada features were implemented in FBX, such
> as blend shapes, proper keyframe baking. constraint baking, exporting all
> actions, etc.
> -I wrote for you guys a proper Collada exporter in a few lines of Code that
> supported the full spec, you guys refused it to add it to mainline Blender.
> -I insisted, the answer was "Yeah we can put it at some development repo
> and if anyone cares about it we move it to mainline". Of course, everyone
> was using FBX , so who would care about Collada?
>
> Now you cry that FBX is evil and blame Unreal, Unity and Autodesk.
> Now you complain that there are not any open standards being pushed.
>
> You know what guys? cry me a river..
>
>
>
>
>
>
>
>
>
> On Wed, Feb 10, 2016 at 2:45 PM, Daniel Stokes  wrote:
>
>> With regards to glTF exporting, we have a glTF exporter as part of the Real
>> Time Engine addon project [1]. The exporter[2] output passes validation[3]
>> for the glTF 1.0 (not sure if draft or final) specification. It is
>> currently missing animation support, and could have better support for
>> materials and textures. This weekend I will move this exporter out of the
>> project it is currently in and in to its own repo so it can more easily be
>> used for creating a simple glTF export addon.
>>
>> [1] https://github.com/Kupoman/BlenderRealtimeEngineAddon/
>> [2]
>>
>> https://github.com/Kupoman/BlenderRealtimeEngineAddon/blob/develop/brte/converters/blendergltf.py
>> [3]
>> https://github.com/KhronosGroup/glTF/tree/1.0-final/specification/schema
>>
>> Regards,
>> Daniel Stokes
>>
>> On Wed, Feb 10, 2016 at 8:20 AM, Fabio Pesari  wrote:
>>
>>> On 02/10/2016 04:44 PM, Ton Roosendaal wrote:
 A crowd-funder for 1 feature only is very risky. What precisely do we
>>> define to fund? Who would crowdfund a developer to just fix bugs and
>>> maintenance for 2 years? I doubt people would pay for that. I wouldn't
>> even
>>> know where to find such a coder...
 For 2.8 we can do a big fund raiser, and include this on the work
>>> planning. I think professionals rather see us to keep working on the
>> whole
>>> pipeline, starting with good PBR shader editing in viewports.
>>>
>>> Why don't you do a fundraiser organized like this:
>>>
>>> Feature X   [---]
>>> Feature Y   [-]
>>> Feature Z   [--]
>>> Maintenance [-]
>>> Marketing   [--]
>>> =
>>> Total   [---]
>>>
>>> When people donate, they can choose where to put their money and if they
>>> don't, it goes to "Maintenance" by default, so most donors will fund
>>> that. Also, any excess money from the implementation of other features
>>> also goes to "Maintenance".
>>>
>>> It'd be even better if there were set goals for each feature (for
>>> example, $40k for Feature X, and of course no limit on "Maintenance"),
>>> so people would know how much they have to donate in order to make sure
>>> the feature they need is implemented (with a disclaimer, of course).
>>>
>>> I think a lot more people are willing to donate if they know exactly
>>> where their money is going.
>>>
>>> I think generic fundraisers often fail because there aren't set
>>> objectives. The FSF recently managed to reach their goal because they
>>> set a reasonable one ($450k), and they aren't nearly as popular as
>>> Blender (you could say the industry hates them).
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers 

[Bf-committers] Request for Collada Importers/Exporters

[Gaia Clary]

Hi.

If you have a working Collada Importer and/or a corresponding Exporter
for Blender and if you think your solution works better than Blender's
own Collada Module, then please tell us where we can take
a look at your solution.

Please can you make it easy for us to find the code by providing
either reliable URL's (which point to the sources YOU mean)
or even better create a new Maniphest for that.

Or if just provide some answers to the
open questions in

https://developer.blender.org/T41071

I am sure you will get attention :)
thanks
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] The future of FBX and/or other formats in Blender

[Gaia Clary]

Can the Collada Fans please move over to the other thread that i just 
opened?
I believe the FBX guys will be thankful for that :)

thanks

On 11.02.2016 00:30, Todor Imreorov wrote:
> Until the code clean up can this exporter at least be included as a
> "testing" addon in trunk? That way you will make it easier for more people
> to try it out and report bugs. It will also save time of the many who
> already use it for godot. If the old one has code that no one wants to
> touch with a stick and is too big, even if written in better style - it is
> useless to the end users. The end user does not care about the style of
> programming. They care if the exporter creates compatible files. Here you
> have an actual game engine developer with huge community support not being
> able to get it in trunk. Heck people are already using his collada exporter
> more than the one with blender.
> On 10 Feb 2016 22:37, "Julian Eisel"  wrote:
>
>> Suggest we don't pollute this mailing list with discussions about
>> who's capable of writing the better Collada Importer/Exporter? This
>> isn't helpful at all.
>>
>> Cheers,
>> - Julian -
>>
>> On 10 February 2016 at 23:21, Thomas Dinges  wrote:
>>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
 -I wrote for you guys a proper Collada exporter in a few lines of Code
>> that
 supported the full spec, you guys refused it to add it to mainline
>> Blender.
>>> "Refused to add it"?
>>>
>>> https://developer.blender.org/T41071
>>> Reading that ticket^^ tells a whole different story.
>>> Reasonable code review comments were made, but then we got no further
>>> response.
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] fixed: Commit e6c58d... breaks debug builds on windows-64

[Gaia Clary]

I updated to "visual studio 2013 update 5" and now building works again.

cheers,
Gaia

On 24.11.2015 20:05, Gaia Clary wrote:
> i found a hint that maybe vs 2013 update 3 fixes this issue.
> i try that and report if it helped.
>
> cheers,
> Gaia
>
> On 24.11.2015 19:40, Gaia Clary wrote:
>> Hi;
>>
>> Today i wanted to update to the newest develop version of blender.
>> But then i found that the commit e6c58df74e1fe8e7921048bc145b6318322541f2
>> seems to break my debug build.
>>
>> I use:
>>
>> Windows-7 64 bit
>> Visual Studio 2013 64 bit version
>> cmake 3.3.2
>>
>> I deleted the build folder and created a fresh build which failed.
>> then i stepped back in time until i found the above mentioned commit.
>> The last commit that works for me is
>> 5e524333719794f140dafee0555ede5fd308b9ae
>>
>> I hope that is helpful for anybody.
>> cheers,
>> Gaia
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Some Ideas for a Blender Plugin System

[Gaia Clary]

One of the benefits of a Blender PLugin System (bps) that i can think of is:
The Collada module could be extracted into a separate plugin.

But this can only work well if the bps does not force us to rebuild a 
plugin for each blender release. Otherwise maintenance would become a 
nightmare, especially because plugins need to be built for multiple 
platforms.

cheers,
Gaia

On 03.11.2015 14:14, Dalai Felinto wrote:
> Hi,
>
> I'm missing the main point here which would be, what is the advantage
> of a C/C++ plugin system over the current Python addon interface?
>
> I'm currently developing an addon which relies on an external C++ SDK.
> I got things working with ctypes and C API. It works pretty fine.
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2015-11-03 10:59 GMT-02:00 Martin Felke :
>> Hi, today i wrote down a couple of more thoughts regarding a plugin
>> system. As said earlier, those serve only as discussion starting points
>> and are not meant yet as design principles made out of cement. :)
>>
>> Fat VS Slim Core
>> 
>> - currently we have a fat core which contains all functionality
>>as monolith
>> - hard to extend and to maintain because it might be everything depends
>>on everything else
>> - idea: a slim, "bootloader like" core, which handles modules and
>>plugins registration and deregistration and serves as API Hub (of
>>existing modules)
>> - modules are not standalone, they communicate via a central core API
>>Hub so they need the core as well
>> - this way the core can track module APIs and provide a fallback (as
>>in exception handler) for missing code / functions (if module or
>>plugin is not present)
>>
>> Modules VS Plugins
>> --
>> - need to distinguish between logical code separation (module) and
>>"physical" separation (plugin, as in shared library or dll)
>> - group existing core functionality to modules (like, an editor could
>>be a module, or even a modifier)
>> - base modules can be provided by "base" plugins, and extension modules
>>by external plugins
>> - plugins can provide parts of modules, entire modules or multiple
>>modules (like nodes maybe, modifiers, new editors, or extensions to
>>editors)
>>
>> Dependencies
>> 
>> - do we want to have inter-plugin dependencies ? For a slim core
>>approach this might be necessary, if plugin A provides a module or
>>part where plugin B 's code depends on
>> - else base modules should be moved / kept in the core, so everyone has
>>a minimum set of functionality without needing to use plugins
>> - but in general, should plugin code only use Core API (the Hub ?)
>>would be better than "directly" accessing other plugins code, because
>>the core might provide the error fallback in case a plugin isnt
>>present
>>
>> Plugin properties
>> -
>> - should be "hotpluggable", addable, removable during runtime
>> - core needs to take care of disabling all related functionality when
>>module is unloaded (closing editor, saving for example)
>> - each plugin needs an unique identifier of some kind, and versioning
>>info
>> - if basis modules are in a plugin, this plugin needs to be flagged as
>>important or official or so
>> - plugins could be classified by their purpose, like provides Module X,
>>extends Module Y, replaces Module Z, removes Module W
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Another try for "Weight from Bone Glow"

[Gaia Clary]

hi.
Once in a while i visit this document  about "Weight from Bone Glow":

http://www2.eng.cam.ac.uk/~rjw57/pdf/r_wareham_bone_glow_amdo_08.pdf

I slowly make progress with understanding the mathematics here. I also 
think that i have a "visual understanding" of how this works. However i 
still struggle with translating equation (5) into a program.  Maybe 
someone can find the time to translate this equation into some pseudo 
code or so ?

Then i maybe can translate this into an "Weight from Glow" Operator that 
work besides the existing "weight from Bone Heat" Operator. Of course if 
someone can do this in a snap, then i would not be sad if you just go 
ahead and make a patch :)

thanks for any feedback and help on this.
cheers,
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: python interface for object statistics ...

[Gaia Clary]

After chatting in the developer IRC i ended up creating a wiki page
for collecting what sort of data could be added to an improved
statistics page (and how such a page should be organised):

http://wiki.blender.org/index.php/Dev:Ref/Requests/User_Interface/BlenderStatisticFlyout

please comment  update this page as required.

cheers,
Gaia

Am 09.03.2012 00:32, schrieb Gaia Clary:
 So i took another round on this and here is my idea
 after i have seen Sean's contribution.

 What about having 3 statistic sets for Scene, Object and Mesh.

 In Object mode the default is the Scene statistic.
 In edit mode the default is the Mesh statistic.

 Here are 3 images how it may look:

 Scene: http://pasteall.org/pic/show.php?id=28055
 Object: http://pasteall.org/pic/show.php?id=28056
 mesh: http://www.pasteall.org/pic/show.php?id=28057

 The statistics sets can be selected at any time.
 Such everybody could adjust them to their own needs.

 Would that be an approach, doable, understandable,  appreciated ?

 cheers,
 Gaia


 Am 08.03.2012 23:04, schrieb Sean Olson:
 This has always bugged me.  Pulling the information that I need out of that
 stats header always feels slower than it should be because you have to
 visually and mentally play puzzle games to figure out the information that
 you are after.  (Even while righting this I looked at my header and said to
 myself, La: 1 - what the hell is that...  ...  oh, lamps.  This happens
 all the time.  When I don't need to put objects on another layer it's slow,
 when I do, it's tedious.  Anyway, I made a mockup of what I would like to
 see.

 A mouse over of the header stats will bring up a flyout of all the relevant
 stats in a much more organized and readable manner.  I personally would
 like to see just a 'stats' button because the header looks messy to me, but
 I'm sure many love those stats with no mouse movement.  Anyway, here is the
 quick mockup - we could also add icons for face/verts/edges that are
 already in the 3dview header to make this more readable.

 Without further ado: The mockup

 http://img716.imageshack.us/img716/7656/ss20120308170416.png

 On Thu, Mar 8, 2012 at 10:39 AM, Ton Roosendaalt...@blender.org   wrote:

 Hi,

 Such changes we better not do. This statistic should be a reliable piece
 of information for the scene. Selection can be drawn next to it, but not
 instead-of.

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 On 8 Mar, 2012, at 19:26, Gaia Clary wrote:

 this patch seems to do what i propose:

   http://www.pasteall.org/29834

 In object mode it shows the derived facecount and derived vertex count
 of the selected objects.
 In edit mode it displays the mesh facecount and the mesh vertex count .

 When i change the selection in Object mode, the numbers update as
 expected.
 When i add/remove/modify a modifier in object mode, the numbers change
 as expected.
 When i select the visible scene, i get the old numbers as expected.

 cheers,
 Gaia
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers


 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] proposal: python interface for object statistics ...

[Gaia Clary]

hi.

Blender currently exposes the number of vertices/edges/faces
of the current visible scene. If i want to know the number
of faces actually used for a single object (after modifiers
have been applied!), then currently i have to do this:

- move the object to an empty layer
- switch to this layer
- read the face count of the object in the top menu bar

The above procedure could be automated by creating
a python script which mimics that behaviour.
But this is an ugly solution because i have to find an empty
layer first, then move the object around just to get that number.

I know, i could calculate that number by creating a copy of the
object mesh, apply the modifiers and then examine the resulting
mesh object. But that sounds like very inefficient to me.

A nice alternative would be to provide the values per Object either
as object properties or via a python function. I would be interested
in getting efficient access to:

- number of faces of an object (taking modifiers into account)
- number of vertices of an object (taking modifiers into account)

It would be nice if these values where available in Edit mode and
in object mode.

Furthermore i propose to add a function:

bpy.context.scene.statistic_info()

which shall return a dictionary containing the statistics information
that is currently provided as string by bpy.context.scene.statistics()

Would these features be problematic to implement ?

best wishes
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: python interface for object statistics ...

[Gaia Clary]

Am 08.03.2012 16:57, schrieb Campbell Barton:
 Why do you want this?
My special usage scenario is this:

When creating content for an online environment (like
Second Life) the content creator  must be aware of the
derived face count of an object as that is a very critical number.
But we only need an estimate. An accurate number is
not necessary here.

So it makes sense to show the derived face count of the
current object selection. The number of derived
faces for the entire visible scene is less interesting IMHO.

So i would be fully satisfied if the Ve: and Fa: values would
contain the estimated number of derived vertices/faces for
the current selection (in object mode) instead of for the
visible scene.

Does that make sense ?

cheers,
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: python interface for object statistics ...

[Gaia Clary]

this patch seems to do what i propose:

 http://www.pasteall.org/29834

In object mode it shows the derived facecount and derived vertex count 
of the selected objects.
In edit mode it displays the mesh facecount and the mesh vertex count .

When i change the selection in Object mode, the numbers update as expected.
When i add/remove/modify a modifier in object mode, the numbers change 
as expected.
When i select the visible scene, i get the old numbers as expected.

cheers,
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: python interface for object statistics ...

[Gaia Clary]

So i took another round on this and here is my idea
after i have seen Sean's contribution.

What about having 3 statistic sets for Scene, Object and Mesh.

In Object mode the default is the Scene statistic.
In edit mode the default is the Mesh statistic.

Here are 3 images how it may look:

Scene: http://pasteall.org/pic/show.php?id=28055
Object: http://pasteall.org/pic/show.php?id=28056
mesh: http://www.pasteall.org/pic/show.php?id=28057

The statistics sets can be selected at any time.
Such everybody could adjust them to their own needs.

Would that be an approach, doable, understandable,  appreciated ?

cheers,
Gaia


Am 08.03.2012 23:04, schrieb Sean Olson:
 This has always bugged me.  Pulling the information that I need out of that
 stats header always feels slower than it should be because you have to
 visually and mentally play puzzle games to figure out the information that
 you are after.  (Even while righting this I looked at my header and said to
 myself, La: 1 - what the hell is that...  ...  oh, lamps.  This happens
 all the time.  When I don't need to put objects on another layer it's slow,
 when I do, it's tedious.  Anyway, I made a mockup of what I would like to
 see.

 A mouse over of the header stats will bring up a flyout of all the relevant
 stats in a much more organized and readable manner.  I personally would
 like to see just a 'stats' button because the header looks messy to me, but
 I'm sure many love those stats with no mouse movement.  Anyway, here is the
 quick mockup - we could also add icons for face/verts/edges that are
 already in the 3dview header to make this more readable.

 Without further ado: The mockup

 http://img716.imageshack.us/img716/7656/ss20120308170416.png

 On Thu, Mar 8, 2012 at 10:39 AM, Ton Roosendaalt...@blender.org  wrote:

 Hi,

 Such changes we better not do. This statistic should be a reliable piece
 of information for the scene. Selection can be drawn next to it, but not
 instead-of.

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 On 8 Mar, 2012, at 19:26, Gaia Clary wrote:

 this patch seems to do what i propose:

  http://www.pasteall.org/29834

 In object mode it shows the derived facecount and derived vertex count
 of the selected objects.
 In edit mode it displays the mesh facecount and the mesh vertex count .

 When i change the selection in Object mode, the numbers update as
 expected.
 When i add/remove/modify a modifier in object mode, the numbers change
 as expected.
 When i select the visible scene, i get the old numbers as expected.

 cheers,
 Gaia
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] About COLLADA item sort order

[Gaia Clary]

Hi.

I want to make a proposal to provide a specific sort order for geometry 
nodes
and material nodes in the exported dae files. It would also be of 
value if the
user had a certain (indirect) influence on that sort order. So my idea 
was to
provide an alphabetic order by item names for items on the same 
parent/child
hierarchy level..)

The main reason for this proposal is a Jira entry from Second Life:

https://jira.secondlife.com/browse/VWR-28436?

Unfortunately that link is secured and i do not think that i am allowed to
publish its content.

Anyways the main issue is that the second life importer uses up to 5 dae 
files with
different LOD levels and physics shapes for ONE single object. The 
problem is that
geometry nodes (and also material nodes) must be given in the same order 
in all
files. Sorting the nodes during export time would be an easy fix for 
this issue.

I believe that this problem should be solved in the Second Life importer 
in first
place. But maybe there are other reasons why supporting a sort order in the
Blender Collada exporter also makes sense...

cheers,
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada-exports: What target software works with them ?

[Gaia Clary]

Hi.

A few days ago i have added some information to the Collada Wiki Page
about which software tools do accept Blender's current Collada exports:

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Import_Export

I now have reorganized the page a little bit so that we can add information
about what works and what not. It would be great if people who use other
3D tools or target  game engines could add some test results
(from Blender 2.61) to the wiki or report here in the mailing list.

As soon as Juha's patch finds its way into trunk, i will also start testing
on trunk, prepare more test cases, and report my own test results on the 
Wiki.

For curious testers: The Wiki page already contains a few dae files for 
testing.
These dae files have been created with Juha's patch and i know they work
for Second Life. But i have not yet seen any feedback from users of other
target software.

So you might be curious and just take the provided dae files, import 
them to your
other tool and report back what breaks or what works for you. That would 
help us
a lot to step forward.

thank you,
Gaia


Am 01.02.2012 10:05, schrieb Gaia Clary:
 Hi.
 Should we fully switch discussion to the Wiki page ?
 I answer here and add a comment to the Wiki as well.

 http://wiki.blender.org/index.php/Dev_talk:2.5/Source/Development/Todo/Import_Export

 More see below...

 Am 31.01.2012 07:51, schrieb Juha Mäki-Kanto:
 Hi, Gaia

 Good to hear it does something right:) In response:

 1.) Does it work ok with maya without the Second Life- box checked? There
 are some other changes to export which may also affect results.
 I have contacted the Maya user for giving me some more help.
 Unfortunately he
 is under pressure and can get to testing only in a few days. I tell you
 the results
 as soon as i get them. In the mean time i try to get a Maya test license.

 2. and 3.) The export with compatibility mode is probably the same as
 2.49b. I still need to do some research on that with different software to
 have a better understanding, but in the end it's a cosmetic/UI issue which
 is the preferred mode if it comes to that.
 I do not understand what you have in mind here. Do you think about
 an export option like:  [ ] enable 90 degree rotation
 Probably it is best to first see if other programs need that rotation thing
 and then decide if such an option is needed at all, or just the code fix
 would be fine.

 4.) The imported bones should come out as the regular rig unless your
 pipeline is modifying the armature somehow? Adding bones for example would
 mess with reinterpreting the bones as lines between joints.
 There is no scripting involved in the tests i made. The current state
 (with your patch):

 export character only: Reimport to Blender results in 3 objects of size 0
 export character+rig: Reimport to blender gives 3 objects of correct
 size plus an
 armature with 90 degree rotation of each bone around z-axis

 I'll probably separate the patch into two parts since the exporting code is
 more straightforward and the compatibility part can be controlled from the
 UI so it should have a better change of making it in. The importer part is
 bit more involved, have to see about it.
 It would be a good starting point to see the exporter patch in trunk. I
 am sure as soon as
 the patch is in Blender, there will be a lot of users going to test it.

 cheers
 Gaia
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada-patch for testing

[Gaia Clary]

Hi.
Should we fully switch discussion to the Wiki page ?
I answer here and add a comment to the Wiki as well.

http://wiki.blender.org/index.php/Dev_talk:2.5/Source/Development/Todo/Import_Export

More see below...

Am 31.01.2012 07:51, schrieb Juha Mäki-Kanto:
 Hi, Gaia

 Good to hear it does something right:) In response:

 1.) Does it work ok with maya without the Second Life- box checked? There
 are some other changes to export which may also affect results.

I have contacted the Maya user for giving me some more help. 
Unfortunately he
is under pressure and can get to testing only in a few days. I tell you 
the results
as soon as i get them. In the mean time i try to get a Maya test license.

 2. and 3.) The export with compatibility mode is probably the same as
 2.49b. I still need to do some research on that with different software to
 have a better understanding, but in the end it's a cosmetic/UI issue which
 is the preferred mode if it comes to that.
I do not understand what you have in mind here. Do you think about
an export option like:  [ ] enable 90 degree rotation
Probably it is best to first see if other programs need that rotation thing
and then decide if such an option is needed at all, or just the code fix
would be fine.

 4.) The imported bones should come out as the regular rig unless your
 pipeline is modifying the armature somehow? Adding bones for example would
 mess with reinterpreting the bones as lines between joints.

There is no scripting involved in the tests i made. The current state 
(with your patch):

export character only: Reimport to Blender results in 3 objects of size 0
export character+rig: Reimport to blender gives 3 objects of correct 
size plus an
armature with 90 degree rotation of each bone around z-axis

 I'll probably separate the patch into two parts since the exporting code is
 more straightforward and the compatibility part can be controlled from the
 UI so it should have a better change of making it in. The importer part is
 bit more involved, have to see about it.
It would be a good starting point to see the exporter patch in trunk. I 
am sure as soon as
the patch is in Blender, there will be a lot of users going to test it.

cheers
Gaia
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada Development (moving forward)

[Gaia Clary]

Hi.
I just have added a few test files to the wiki page:

 
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Import_Export

At the moment i only added a rigged character, no animation tests yet.
@Toni: Does it make sense to also add your 4characters.zip to the page ? 
I understand that you will keep an eye on the animation export parts ?

Discussion could take place in the discussion section of the wiki 
page. I added a first comment to:


http://wiki.blender.org/index.php/Dev_talk:2.5/Source/Development/Todo/Import_Export#Collada_Task_Force_Discussion

I can take care of keeping this page up to date and add new tests if 
necessary and remove obsolete stuff from there. Right now i added Juha's 
proof of concept patch to that page. And i hope we can get the final 
patch added to trunk soon. then i believe that testing will become much 
easier and will be done by more users.

cheers,
Gaia

Am 31.01.2012 13:20, schrieb Toni Alatalo:
 On Tue, 2012-01-31 at 13:37 +0200, Toni Alatalo wrote:
 for SL, the Blender Collada export for animated meshes+skels to GLGE
 doesn't break. I can put a little working demo up now with the current
 exports and update it when changes are made in Blender.
 ok is online now at:
 http://www.realxtend.org/webnaali/animtest.html

 screenshot of the expected result (with chrome or recent firefox etc)
 http://www.realxtend.org/download/glge-animtest.png

 plays back a set of motion captured animations in a loop. the mesh and
 the skeleton is from Make Human btw.

 that collada is exported apparently with a fairly old version :)
 Blender 2.56.0 r34074
 next step i think is to verify that current Blender gives the same
 correct result.

 the blend is available in http://www.realxtend.org/download/4avatars.zip
 is someone wants to repeat or use that for some purpose btw (is creative
 commons some liberal license).

 if there is some more suitable forum for collada test and dev talks
 let's use that to not flood this one in the future.

 Domino
 ~Toni
 same.


 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada-patch for testing

[Gaia Clary]

Hi, kanttori;

Your patch works fine for export. For import see remark 4.) below.

I first had some issues but it turned out that i made a mistake when i 
disabled
our workaround code for the current Collada exporter.  After i fixed our 
tools
and removed all these (ugly) workarounds all is well now.

Some remarks which may be of common interest regarding this patch:

1.) The exported .dae files from your patch also seem to be importing 
well into Maya
while the current .dae exports from official Blender Collada fail 
miserably on Maya.

2.) Your patch seems to make Blender trunk compatible with Blender-2.49b
We never had issues with .dae exported from 2.49b (neither for Maya nor 
for Second Life)

3.) Therefore i also believe that the explicit mentioning of Second 
Life in various
places in the patch is not necessary , because i believe it is not a 
patch to make Collada
compatible to Second Life, but a major fix of something where possibly 
Collada
standards do not tell explicitly how the export has to be done and 
Blender does
it maybe correct but in a not so lucky way.

4.) Blender itself can now import its own .dae files which seems to be a 
major improvement,
but a first inspection shows that the bones are rotated by 90 degrees 
after import, which
results in exactly(!) the same rig that we used as workaround for 
getting exports to work
with the current Collada exporter ;)

Thanks for that great step towards a better Collada world :)

cheers,
Gaia

Am 29.01.2012 20:31, schrieb Juha Mäki-Kanto:
 Hi,

 I've been looking into collada, mainly from the transforms-side of things
 (since I know more about them then collada). Here's a patch in
 pasteallhttp://www.pasteall.org/28655/diffand brief
 synopsishttp://www.pasteall.org/28656/text. Would like to know if it
 fixes export to second life (via compatibility check box in the export
 dialog) and if this then works with animation exported from blender which
 afaik is BVH. Should also fix #29246 and #29082 which are import-problems
 of animation and armature.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Gaia Clary]

I have done a couple of tests with Blender 2.61 to check if it exports 
correct for Second Life.
For some reason it takes a long time to export an animatin which 
actually does not exist.
Yes i have unchecked export animation :)
The import to Second Life yields import errors.
I havent tested in more depth. Maybe the script behaves wrong
because it was made for 2.58 ?

cheers,
Gaia

Am 07.01.2012 19:16, schrieb skoti:
 I wanted to test your exporter on my example scene, but there are errors
 and the files are not compatible with the specification - for example in
 light you have a childoptics ... in the specification have
 clarified that the optics may be only child ofcamera.

 On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote:
 Ah, I tried to attach it to the e-mail, guess the mailing list does not
 accept attachments?

 Here's a dropbox link:

 http://dl.dropbox.com/u/53086520/io_scene_dae.zip

 Cheers

 Juan Linietsky

 On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenmikkels...@gmail.comwrote:

 In my case I do not need morphs. I do need animation and skinning though.
 And obviously
 also geometries and materials. And it sounds like you have this covered?
 I have no sense of loyalty toward OpenCollada so if this is a viable
 solution
 I am for it. Can you make it available somewhere with instructions on how
 to install it so people can test it?

 Cheers and thanks,

 Morten


 On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietskyredu...@gmail.com   wrote:

 Hi guys,

  I made my own Collada exporter in Python and that's what I've been
 using. It's less than 1k lines of code and does not depend upon any
 library
 or anything, but it exports everything except morphs. I don't have much
 time to work on it at the moment, but it's so simple and complete that if
 anyone else want's to work on it, it should be really easy. I'm also not
 an
 expert at Python or Blender API so someone more experience can probably
 shape it up better. It's also much more stable than the official one (due
 to it being so small).

 Feel free to do anything with it or integrate it into Blender, just
 credit
 me on the file. I would love to work more on it, or even make a proper
 importer since I have a high level of expertise in Collada, but I have
 very
 little time and must work to earn my meals.

 Cheers!

 Juan Linietsky


 On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsenmikkels...@gmail.com
 wrote:
 Yes that's a very relevant point. A collada solution with just
 positions,
 UVs and normals
 is not a solution. In that case you might as well use obj format.
 I went through the hard work of writing a collada importer specifically
 to
 get skinning and animation
 into my tech frame-work.


 On Sat, Jan 7, 2012 at 5:03 AM, skotiskot...@o2.pl   wrote:

 I know Collada importer / exporter is problematic (I wrote an
 importer
 for my engine and I know that everything in the Collada can be stored
 in
 N different ways).

 - If you want to use the model in Second Life / Google Earth, you
 have
 to use Collada, if you want to use models in engines WebGL/Flash3D
 practically have to use Collada (is there any web engine with FBX
 importer?), Most game engines use Collada for importing data (support
 for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
 blender, but it is not usually an option for people using Collada.

 - If someone uses Collada it not for the base mesh + uv (then using
 *.
 obj) and for skeletal animation, lights, cameras and their animation
 (motion, color, light and their intensity), multiUV (uv for color,
 normalmap ... + uv for lightmap). And all this in current Collada
 exporter works well.

 - No other exporter does not work here as well as Collada - ofc has
 bugs, but it has nothing what could replace the Collada in this task.
 In
 the future, Alembic can replace Collada, but not for several years.

 IMO, better to leave Collada, until you will be able to replace it
 with
 success to other formats like Alembic (FBX is not popular in the
 software and you can not replace him Collada in most tasks).


 On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
 Hi,

 I realize the proposal was harsh, but it was meant as a public
 statement
 as well (to khronos, opencollada team, etc). I don't want to blame it
 on
 the hard working devs here. We do have collada IO work at some level,
 and
 that has been proven useful in several cases. The job is just
 incredible
 hard to achieve.
 To move forward:

 - userts who successfully applied .dae could also check whether
 another
 exchange format would have done the job as good. Tried FBX?
 - note that for basic mesh (+uv) export, a quite simple script
 could
 do
 the job already. It is probably a few days job for a py scripter.
 - we are currently including about 100 MB of opencollada libs to
 make a
 feature work that's meant to be able to exchange (I+O) full shots or
 game
 environments, with character animation and so on. That's what Collada
 was
 designed for, and 

Re: [Bf-committers] Collada importer/exporter kickout

[Gaia Clary]

Would it be an option to separate the current Collada implementation
into an addon module, which is disabled by default, but can be enabled
from the addon panel ? (with a text flagging it as Experimental for 
example)

This would keep it out of view for everybody who does not need it.
But people who actually work with the current Collada exporter
could still enable it easily.

-gaia-


Am 06.01.2012 11:58, schrieb Ton Roosendaal:
 Hi,

 I think it's a bad precedence to create a tracker for every feature we notice 
 is badly supporting or failing. Just moving reports to another tracker is not 
 solving anything of course.

 I would rather tackle it more political  practical:

 1) Official announcement that Blender drops Collada support
 2) Move Collada support into a branch, out of trunk
 3) Create a tracker orphanage or branches or so, where we put all reports 
 that are not in support (anymore).

 BTW:

 I've personally had it with Collada and its supporters. Next time we add this 
 back in Blender it should be based on well defined and tested use cases, on a 
 level we (or the branch team) can support it. In my opinion that's proven to 
 be impossible, for reasons how Collada works, designed and has been organized.

 Three months ago already I wrote this open letter:
 http://code.blender.org/index.php/2011/10/collada-momentum/

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 On 4 Jan, 2012, at 20:57, Sergey Sharybin wrote:

 Hi,

 As everybody noticed current collada importer/exporter is very buggy which
 seems to make this format almost useless in Blender. And what's much worse
 -- we don't actually have developer who maintains this area.

 We discussed this already with Campbell and found that OpenCollada itself
 isn't actually maintaning -- there are only few commits in several months.
 Ofcourse it doesn't mean this library is useless and all bug from our
 tracker is related on that issues, but still.. Maybe the time have come to
 re-think this importer/exporter (investigate if it's possible to fix issues
 in clear way, check if design is good enough -- not sure, haven't touched
 this code deep myself)?

 Here's our proposal:
 - Move all collada-related issues into it's own tracker. Like it was done
 with BGE, it might help finding volunteer to fix them. Also, people will
 see that it's not actually core stuff and that it's community-supported.
 - Disable collada in release builds. It's not useable and only seems to be
 making artists disappointed.

 More optimistic targets would be find volunteer to pick up this stuff who
 will make it usable (maybe rewritting this stuff from scratch..)

 -- 
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal to improve the File Selector Box for import/export and open/save

[Gaia Clary]

Hi.

I created another example where i believe that my proposal
makes sense:

 http://www.pasteall.org/pic/show.php?id=21934

I have used a screen width of 840 which i believe is an extreme case
and almost nobody will ever use such a narrow screen. But even
there it appears to me like very usable and not a waste of space
compared to what we have today:

 http://www.pasteall.org/pic/show.php?id=21935

If the right sidebar in my proposal really gets in the way it always
can be hidden. What i dislike in my proposal is the location of the
Export Obj button. Any ideas ?

If i get any positive feedback, then i will dig deeper into this and if i
could get some initial help where to start changing the source code
i will try to make a patch for this request :)

cheers,
Gaia

Am 04.12.2011 00:17, schrieb Gaia Clary:
 Hi.

 I found it is very common to overlook the Properties section during
 export or import
 or even when loading/saving another blend file. The properties settings
 are often burried
 somewhere outside of the screen on the lower left side of the file
 selection window.

 I propose to move the special properties from bottom left to top right
 as shown
 for the Collada export in this fake image:

   http://www.pasteall.org/pic/show.php?id=21892

 In detail i propse:

 - add Properties and tool shelf to the export selection menu
 - put the export properties into the properties section
 - put all the rest into the tool shelf
 - display the tool shelf on the left (similar to the 3D View)
 - display the properties on the right (similar to the 3D view)

 Main Reasons for the proposal:

 1.) The action button and the related properties would be side by side
 instead of in opposite corners of the screen (as it is now)
 2.) The screen area would be better utilised (more info on less space)
 3.) The gui would become more consistent (properties+toolshelf as in 3D
 View)

 Where would i have to start if i wanted to add a patch to my proposal ?
 Is there any entry point or documentation hint available for how the Gui
 is programmed ?

 Cheers,
 Gaia

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposal to improve the File Selector Box for import/export and open/save

[Gaia Clary]

Hi.

I found it is very common to overlook the Properties section during 
export or import
or even when loading/saving another blend file. The properties settings 
are often burried
somewhere outside of the screen on the lower left side of the file 
selection window.

I propose to move the special properties from bottom left to top right 
as shown
for the Collada export in this fake image:

 http://www.pasteall.org/pic/show.php?id=21892

In detail i propse:

- add Properties and tool shelf to the export selection menu
- put the export properties into the properties section
- put all the rest into the tool shelf
- display the tool shelf on the left (similar to the 3D View)
- display the properties on the right (similar to the 3D view)

Main Reasons for the proposal:

1.) The action button and the related properties would be side by side
   instead of in opposite corners of the screen (as it is now)
2.) The screen area would be better utilised (more info on less space)
3.) The gui would become more consistent (properties+toolshelf as in 3D 
View)

Where would i have to start if i wanted to add a patch to my proposal ?
Is there any entry point or documentation hint available for how the Gui
is programmed ?

Cheers,
Gaia

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] r42085: cmake build on windows WITH_CYCLES enabled fails (for me)

[Gaia Clary]

Hi.

when i try to build using cmake on windows, then i get 2 errors:

cl : Command line error D8016 : '/Ox' and '/RTC1' command-line options 
are incompatible
109LINK : fatal error LNK1104: cannot open file 
'..\..\lib\Debug\cycles_kernel.lib'

I can build just fine when i disable WITH_CYCLES


Here is my setup:

- Windows-7 64 bit.
- visual c++ 2008 Express Edition


Test 1: Build without cycles:


Cmake shows these changes:

Commandline options:

-DCMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender 
-DCMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo 
-DWITH_CYCLES:BOOL=0


Cache file:

CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender

CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo

WITH_CYCLES:BOOL=0


I build - build INSTALL

and get a working blender executable



Test 2: Build with cycles:



Cmake shows these changes:

Commandline options:

-DCMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender 
-DCMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo 
-DWITH_CYCLES:BOOL=1


Cache file:

CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender

CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo

WITH_CYCLES:BOOL=1


I build - build INSTALL

and get 2 errors:

cl : Command line error D8016 : '/Ox' and '/RTC1' command-line options 
are incompatible
109LINK : fatal error LNK1104: cannot open file 
'..\..\lib\Debug\cycles_kernel.lib'


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] r42085: cmake build on windows WITH_CYCLES enabled fails (for me)

[Gaia Clary]

It works now like a charm!
Thank you for the quick response and fix :)

-gaia-

Am 23.11.2011 17:31, schrieb Brecht Van Lommel:
 I've committed a possible fix for this, please test :)

 Thanks,
 Brecht.

 On Wed, Nov 23, 2011 at 4:17 PM, Gaia Clary
 gaia.cl...@machinimatrix.org  wrote:
 Hi.

 when i try to build using cmake on windows, then i get 2 errors:

 cl : Command line error D8016 : '/Ox' and '/RTC1' command-line options
 are incompatible
 109LINK : fatal error LNK1104: cannot open file
 '..\..\lib\Debug\cycles_kernel.lib'

 I can build just fine when i disable WITH_CYCLES

 
 Here is my setup:

 - Windows-7 64 bit.
 - visual c++ 2008 Express Edition

 
 Test 1: Build without cycles:
 

 Cmake shows these changes:

 Commandline options:

 -DCMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender
 -DCMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo
 -DWITH_CYCLES:BOOL=0


 Cache file:

 CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender

 CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo

 WITH_CYCLES:BOOL=0


 I build -  build INSTALL

 and get a working blender executable


 
 Test 2: Build with cycles:
 


 Cmake shows these changes:

 Commandline options:

 -DCMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender
 -DCMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo
 -DWITH_CYCLES:BOOL=1


 Cache file:

 CMAKE_INSTALL_PREFIX:PATH=C:/Program Files (x86)/Blender

 CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release;MinSizeRel;RelWithDebInfo

 WITH_CYCLES:BOOL=1


 I build -  build INSTALL

 and get 2 errors:

 cl : Command line error D8016 : '/Ox' and '/RTC1' command-line options
 are incompatible
 109LINK : fatal error LNK1104: cannot open file
 '..\..\lib\Debug\cycles_kernel.lib'


 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] 2.6 section in Wiki not (yet) fully set up ?

[Gaia Clary]

Hi.

I just wanted to start documenting some changes on the User interface 
for Blender 2.6. But most pages are only available for 2.5 and they all 
are marked with Do not modify page. Is it planned to copy the 2.5 
documentation into the 2.6 section ? Or are we supposed to create the 
pages as we update them for 2.6 ?

How shall i proceed now ? I could not find any documentation for how to 
migrate an existing page to a new release.

-gaia-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch for naming of UVTexture Layer

[Gaia Clary]

I believe that the term UVTexture Layer and related terms are a bit 
confusing on the User interface level. So i created a patch which 
renames some GUI elements:

http://www.pasteall.org/26581

In particular:

UV Texture - UV Layer (text label)
UVTex - UVLayer (default name of new UVLayer)

UV Texture Layer - UV Layer
Name of UV unwrapping layer - Name of UV Layer
Active UV Texture - Active UV Layer
Active UV Texture Index - Active UV layer IndexAdd UV texture 
layer - Add UV layer
Assign Image to UV Texture - Assign Image to UV Layer
Remove UV texture layer - Remove UV Layer

I hesitate to add this patch to the patch tracker because it may not be 
acurate or even wrong. Hence i ask for your feedback on this.

thanks a lot
-gaia-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch for naming of UVTexture Layer

[Gaia Clary]

In fact it is NOT a UV Map. The construct is more a container which 
contains
a UV Map and a set of textures, so:

UV Layer = 1 UVMap + n Texture(s)

That's why its not called UV Map. So what would be a better name then ?
maybe UVContainer comes to mind. But that's also questionable IMHO.

BTW i meanwhile have added the Patch to the patch tracker as proposed by
Ideasman_42:

http://projects.blender.org/tracker/index.php?func=detailaid=29336group_id=9atid=127

There is a bit more of explanation.
-gaia-

Am 20.11.2011 17:01, schrieb Daniel Salazar - 3Developer.com:
 I think the correct term is uv map, uv maps cant be layered so why
 naming them like that? There can be *multiple* UV maps of course but
 they have no relation between them. The relation is defined in their
 usage, let it be textures that can be layered of course or any other
 type of usage for a UV map.

 If UVs are layers, why arent vgroups layers too? Also why not stick to
 what is the standard terminology?

   I don't know if you see my point or i need to explain my self better

 good day

 Daniel Salazar
 3Developer.com



 On Sun, Nov 20, 2011 at 3:18 AM, Gaia Clary
 gaia.cl...@machinimatrix.org  wrote:
 I believe that the term UVTexture Layer and related terms are a bit
 confusing on the User interface level. So i created a patch which
 renames some GUI elements:

 http://www.pasteall.org/26581

 In particular:

 UV Texture -  UV Layer (text label)
 UVTex -  UVLayer (default name of new UVLayer)

 UV Texture Layer -  UV Layer
 Name of UV unwrapping layer -  Name of UV Layer
 Active UV Texture -  Active UV Layer
 Active UV Texture Index -  Active UV layer IndexAdd UV texture
 layer -  Add UV layer
 Assign Image to UV Texture -  Assign Image to UV Layer
 Remove UV texture layer -  Remove UV Layer

 I hesitate to add this patch to the patch tracker because it may not be
 acurate or even wrong. Hence i ask for your feedback on this.

 thanks a lot
 -gaia-
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch for naming of UVTexture Layer

[Gaia Clary]

I tried to  take into account what brecht wrote the other day:

Citation from Brecht about the meaning of UV Texture Layer:

| The layer is called UV Texture Layer because it contains both UV
| coordinates and an image texture for each face (and some other texture
| face properties before the changes in 2.60). Modifiers and other
| places that use these usually have properties called UV Layer, because
| they only use the UV coordinates part.
|

However i agree that just naming it UV Map would make this area much more
streamlined and thus easier to document and teach. But i am the last one
to judge this because i can not tell if a decision to name it UV Map 
might add
confusion at different places. So if the agreement is UV Map i would 
be more than
happy with it and change the patch accordingly :)

Note that only the fact that Brecht mentioned:

| So there is a reason for the naming, though it may not be that clear
| and not always applied consistently...

made me start with the patch at all, because he motivated me to give it
a try and show up with a reasonable proposal.

Cheers,
Gaia


Am 20.11.2011 23:46, schrieb Daniel Salazar - 3Developer.com:
 Elaborating, the fact that a common feature has some extra
 functionality related to Blender specific design is not a good reason
 to get creative about such common names. Blender's vertex/edge/faces
 can store other data too, however this is secondary, no need to
 name them something fancy because of that right? and this last years a
 lot of effort has been made into streamlining blender in this sense.
 It's easier to explain that our UV maps can also store image links for
 use in X and Y feature in the game engine or what ever than coming out
 with a new name just because of some extra functionality.

 cheers

 Daniel Salazar
 3Developer.com



 On Sun, Nov 20, 2011 at 4:17 PM, Daniel Salazar - 3Developer.com
 zan...@gmail.com  wrote:
 Frankly i couldn't care less about the face texture assignment, it's
 only used by legacy features AFAIK. UV Map is the generic name that
 anyone recognizes.

 You would need to give strong reasons NOT to use the generic name of a
 feature so common in CG, not the other way around!! Start simple, if
 really needed change it the least possible. We are not alone in the CG
 world neither invented UV Mapping ;)

 http://en.wikipedia.org/wiki/UV_mapping

 Daniel Salazar
 3Developer.com



 On Sun, Nov 20, 2011 at 10:09 AM, Gaia Clary
 gaia.cl...@machinimatrix.org  wrote:
 In fact it is NOT a UV Map. The construct is more a container which
 contains
 a UV Map and a set of textures, so:

 UV Layer = 1 UVMap + n Texture(s)

 That's why its not called UV Map. So what would be a better name then ?
 maybe UVContainer comes to mind. But that's also questionable IMHO.

 BTW i meanwhile have added the Patch to the patch tracker as proposed by
 Ideasman_42:

 http://projects.blender.org/tracker/index.php?func=detailaid=29336group_id=9atid=127

 There is a bit more of explanation.
 -gaia-

 Am 20.11.2011 17:01, schrieb Daniel Salazar - 3Developer.com:
 I think the correct term is uv map, uv maps cant be layered so why
 naming them like that? There can be *multiple* UV maps of course but
 they have no relation between them. The relation is defined in their
 usage, let it be textures that can be layered of course or any other
 type of usage for a UV map.

 If UVs are layers, why arent vgroups layers too? Also why not stick to
 what is the standard terminology?

I don't know if you see my point or i need to explain my self better

 good day

 Daniel Salazar
 3Developer.com



 On Sun, Nov 20, 2011 at 3:18 AM, Gaia Clary
 gaia.cl...@machinimatrix.orgwrote:
 I believe that the term UVTexture Layer and related terms are a bit
 confusing on the User interface level. So i created a patch which
 renames some GUI elements:

 http://www.pasteall.org/26581

 In particular:

 UV Texture -UV Layer (text label)
 UVTex -UVLayer (default name of new UVLayer)

 UV Texture Layer -UV Layer
 Name of UV unwrapping layer -Name of UV Layer
 Active UV Texture -Active UV Layer
 Active UV Texture Index -Active UV layer IndexAdd UV texture
 layer -Add UV layer
 Assign Image to UV Texture -Assign Image to UV Layer
 Remove UV texture layer -Remove UV Layer

 I hesitate to add this patch to the patch tracker because it may not be
 acurate or even wrong. Hence i ask for your feedback on this.

 thanks a lot
 -gaia-
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers