BLENDER_SUBVERSION - this is for internal versions only, we could do
an incremental release without changing it. (2.60 and 2.60a could have
the same BLENDER_SUBVERSION for eg).
alternately it could be bumped multiple times in 1 week, but this of
course doesn't indicate we did 3 point releases.
2.6
How was this done in previous releases?
Do kind of agree that it should be 'set(PATCH_VERSION
${BLENDER_SUBVERSION})' because BLENDER_VERSION_CHAR doesn't really
give as much useful information (and caused problems with the debian
packager in the past).
Plus that change would make CPack just a li
>
> >So why not to simply adding possibility for generate/access a tangent
> >normals into the python api?
>
If it's not already available in the python API then I agree that it's a
good idea.
However, you'd need to supply support for normals as well since
at this point the python API only gives
You should be careful referring to them as "compliant". I understand what
you mean that they are compliant in "format".
But as is explained here -->
http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps
the only way to be fully compliant is to use the exact same spaces that
were u
On Nov 14, 2011, at 11:07 AM, David wrote:
> Oops, attachment got lost...
Hm, it doesn't seem to accept my attachment. Anyways, the code is here:
http://lists.blender.org/pipermail/bf-cycles/2011-November/000352.html
Sorry for the noise.
P.S.:
If you are wondering why you should care, here is
Hello
Dear Nathan, first of all, thanks for all your work :)
According to
http://www.blender.org/forum/viewtopic.php?t=18145&sid=f92f437b3a4ad3aa31e1342e460f83f3
it
seems it's on your mind to implement custom properties export code on the
Collada plugin.
I am currently about to begin a project t
At least, build scripts in build_files/package_spec/ and Debian's
official distribution package use BLENDER_VERSION_CHAR.
I don't think the package creation systems should follow the different
versioning rule.
(2011/11/15 01:24), Bastien Montagne wrote:
> Maybe I’m wrong, but imho the package cre
In the last days I've been doing a blender->ogre material converter
and after learning how each engine calculates the normals from tangent
normal maps, I've found that Ogre::Mesh::buildTangentVectors builds
the necessary vectors compatible with blender ones. It has a couple of
options for splitting
Maybe I’m wrong, but imho the package creation system should rather use
the BLENDER_SUBVERSION number (currently 4, we are in 2.60.4), rather
than BLENDER_VERSION_CHAR...
Le 14/11/2011 17:18, IRIE Shinsuke a écrit :
> Thanks for the recommit.
>
> Of course the build scripts use the svn revision,
Thanks for the recommit.
Of course the build scripts use the svn revision, but also have to use
the version character like "2.60.1+svn41828", where ".1" is translated
from "a".
For example, most package systems compare the versions as:
2.60 < 2.60+svn41834 < 2.60.1 < 2.60.1+svn41834 < 2.60.
Recommited "a".
Although I think this is wrong, this is only intended for a release.
If you want to make svn snapshot packages you should use the svn revision.
Am 14.11.2011 14:30, schrieb IRIE Shinsuke:
> When BLENDER_VERSION_CYCLE was changed to beta (r41802),
> BLENDER_VERSION_CHAR also was res
Hi!
One more question, if I may.
I've seen that there is a couple of the exporter programs which can
generate tangents to export for specific 3D engines only, like OgreExporter.
So why not to simply adding possibility for generate/access a tangent
normals into the python api?
I am not saying that
Hi,
I have thinking of a way of managing both modelview and projection
matrix for specificity of CAVE systems management. I updated the
projects.blender.org patch submit page to explain the solution I
propose. Moreover, I include a new version of the patch that propose
this solution.
I'm not aw
Hi...
On a recent introductory workshop I made I realized how weird and
confusing the current workflow with uv textures is, especally when it
comes to texture painting. For example try explaining to a novice that
what they see as a texture on an object in the viewport could depend
either on the uv
When BLENDER_VERSION_CYCLE was changed to beta (r41802),
BLENDER_VERSION_CHAR also was reset to blank. As the result, build
scripts like build_files/package_spec/build_debian.sh recognize the
Blender's version as 2.60, which is less than 2.60a, and the
version-down confuses the package system so th
I am mostly OK with the term "UV Layer" in modifiers and other places
which use only the UV coordinates part. Why is it called "layer", can
UV layers be stacked ? Where, how and for what reason ?
From a users viewpoint: how and where can we access "UV Textures" in
the "UV Textures Layer"? Are th
On Nov 14, 2011, at 11:02 AM, David wrote:
> [Forwarding to bf-committers since it's not really cycles specific]
Oops, attachment got lost...
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committer
[Forwarding to bf-committers since it's not really cycles specific]
On Nov 14, 2011, at 6:47 AM, David wrote:
> On Nov 13, 2011, at 2:29 PM, Brecht Van Lommel wrote:
>> Hi,
>>
>> I think dithering by adding some random noise as Blender does
>> currently isn't all that useful, and think that erro
Committed r2610, thanks for the patch!
On Sun, Nov 13, 2011 at 12:27 PM, Daniel Salazar - 3Developer.com
wrote:
> Great news! very appreciated and important
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Sat, Nov 12, 2011 at 4:33 PM, Ejner Fergo wrote:
>> Hola,
>>
>> Despite some recent changes
Might it be better to check if em->faces.first == NULL before calling
finalDM->drawMappedFaces ?
On Mon, Nov 14, 2011 at 7:06 PM, Lukas Toenne
wrote:
> Revision: 41823
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41823
> Author: lukastoenne
> Date:
20 matches
Mail list logo