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
lukas.toe...@googlemail.com wrote:
Revision: 41823
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41823
Author:
Committed r2610, thanks for the patch!
On Sun, Nov 13, 2011 at 12:27 PM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
Great news! very appreciated and important
Daniel Salazar
3Developer.com
On Sat, Nov 12, 2011 at 4:33 PM, Ejner Fergo ejner...@gmail.com wrote:
Hola,
Despite
[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 error
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
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 there
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
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
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
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
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 reset
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.2 2.61
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,
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
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
Hello
Dear Nathan, first of all, thanks for all your work :)
According to
http://www.blender.org/forum/viewtopic.php?t=18145sid=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
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
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
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
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.
19 matches
Mail list logo
