Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41823] trunk/blender/source/blender/ editors/space_view3d/drawobject.c: Fix for #29241, ocean sim modifier crash when removing al
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: lukastoenne
Date: 2011-11-14 08:06:24 + (Mon, 14 Nov 2011)
Log Message:
---
Fix for #29241, ocean sim modifier crash when removing all vertices.
The object draw method did not check for valid data when mapping back to
original face, constructive modifier on empty mesh does that.
Modified Paths:
--
trunk/blender/source/blender/editors/space_view3d/drawobject.c
Modified: trunk/blender/source/blender/editors/space_view3d/drawobject.c
===
--- trunk/blender/source/blender/editors/space_view3d/drawobject.c
2011-11-14 07:18:32 UTC (rev 41822)
+++ trunk/blender/source/blender/editors/space_view3d/drawobject.c
2011-11-14 08:06:24 UTC (rev 41823)
@@ -2696,7 +2696,8 @@
{
EditFace *efa = EM_get_face_for_index(index);
- if (efa-h==0) {
+ /* efa=0 for constructive modifier on empty mesh */
+ if (efa efa-h==0) {
GPU_enable_material(efa-mat_nr+1, NULL);
return 1;
}
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FBX camera
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 some recent changes to the FBX exporter, it still didn't export the correct focal length. I fixed this and also worked out how to export the film offset (shift_x/shift_y) correctly. Tested on Maya, Nuke and Houdini. Patch is here: http://projects.blender.org/tracker/?group_id=9atid=127func=detailaid=25979 Exporting to Maya is as good as complete - at least all essential settings are included and works as expected. Nuke and Houdini also get the correct settings (Houdini doesn't set the film offset though, even when importing from Maya), but these two apps has a wrong local rotation of the camera so it's not so useful yet. A big missing feature for all apps is focal length animation. I couldn't test in Unity 3D unfortunately so would appreciate some feedback about how it works in that and other FBX aware apps. Best regards, Ejner ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-cycles] Dithering in preview mode
[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 diffusion should be added once. That's too slow for preview rendering though, and I'm not sure if dithering is really needed in the preview render. Okay, I agree that dithering the preview is probably not really necessary. I wanted to see how fast error diffusion would be, and you are right, my implementation takes about 200ms for a HD frame, which is a bit slow for interactive preview. The quality of the dithering is a bit nicer though, so maybe this could be useful to have in trunk. ___ Bf-cycles mailing list bf-cyc...@blender.org http://lists.blender.org/mailman/listinfo/bf-cycles ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-cycles] Dithering in preview mode
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-committers
Re: [Bf-committers] Are UV Texture Layer and UV Layer synonyms for UV Map ?
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 Functions available like : - Show the textures on the UV Texture Layer - Add/Modify/remove the textures on the UV Texture Layer Maybe the UV Texture layer got its name because it is technically a container ? But in practice an UV Layer contains a UV Map and associations to multiple Textures which are named UV Textures only because of that association ? And there is yet another pair of terms: UV Layout and UV Map. How are those two related to each other ? -gaia- Am 14.11.2011 04:07, schrieb Brecht Van Lommel: 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. So there is a reason for the naming, though it may not be that clear and not always applied consistently... Brecht. On Sun, Nov 13, 2011 at 4:32 PM, Jassgaia.cl...@machinimatrix.org wrote: Hi. I located following terms in Blender and Blender documentation: UV-Texture UV-Map UV Layer UV Texture Layer And it looks a bit like the terms sometimes get mixed up. I scrolled over different areas in the Blender-GUI and i found: in Image editor: - Export UV Layout In Object properties (texture section) - Mapping - UV In Object Properties (Object Data Section) - UV Texture - UVTex (default name of new UV texture) - Add UV Texture Layer (in tooltip) In Modifer (UV Project Modifier) - UV Layer - UV Layer name (tooltip) After trying to identify the differences between the above mentioned terms I derived the following definition for these terms. Please can you tell me if this is correct, or clarify where i am wrong ? UV Map: Map which relates the faces of a mesh to areas on a 2-dimensional image.** UV Texture Layer: Synonym for UV Map UV Layer: shortform of UV Texture Layer UV Texture: A texture which needs a UV Map to be projected on the surface of an Object If the first 3 terms are indeed synonyms, then i propose to replace them by one single term. I think UV Map would be the one to use and then we have only: UV Map ( a map between faces on an object and corresponding locations on a 2D image) UV Texture (an image that uses a UV Map) what do you think about this ? If i am right then this change would make it much easier to understand UV texturing with Blender and it would become much easier to explain it... ___ 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] Why was BLENDER_VERSION_CHAR cleared?
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 that the newer version becomes not installable. Please keep BLENDER_VERSION_CHAR until 2.61 release! -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Are UV Texture Layer and UV Layer synonyms for UV Map ?
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 layer (which must be set by doing the round-trip to editmode-uv editor-set texture,) or the material (if you have GLSL enabled). I can't describe the glares of miscomprehension coming from the audience but I am sure you can easily get the idea. Intuitively the 3D viewport should show the material texture and show a different one when texture painting. Uv editor should be used just for preview of images on a given uv layout. This is of course just one take on the matter. Maybe people would like a way to, for example preview images on a model in the 3D view. Again, in my opinion, the round trip to image editor to set the image and back is unnecessary. Note that it is also possible to set a different material with different textures on different faces. I don't see why it's necessary to be able to assign different textures for faces as well since there is already one mechanism, albeit marginally more complicated ( though not more intuitive! ), to do the same thing. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improvement of BGE rendering for CAVE systems
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 aware of all technical details of OpenGL rendering of Blender. So there may be a smarter solution that I can work on. Feel free to review my patch and explain me the bugs that could result in such update. Regards Damien Touraine On 05/11/2011 07:00, Damien Touraine wrote: Hi, Jorge pointed me that you were one of the most concerned developper on such feature. I have putted the patch on projects.blender.org. Its ID is : 29161. I'm not sure it covers all the cases (mainly regarding scene optimization rendering). That is a first step (but fundamental) to manage CAVEs. Wall of simulation (ie : high definition wall by patchwork of several projectors) can be seen as CAVE, as the stereoscopic point of view is the one of the big wall, not the one of each screen. We could support CAVEs natively inside blender. But I'm not familiar enough in blender to have a clear idea of what have to be done. Our main problem resides on the the synchronization of the dynamic elements between each computer that participate to the CAVE rendering. This integration may be a bottomless pit: there is several kind of CAVE, several kind of trackers and interactors (position, gesture, voice, ...). That may be interesting to integrate haptic devices (ie: sensorial feedbacks) connected to the physical similator of Blender ... Our first goal is to use poor connection to blender by extracting usefull informations and distributing these with python scripts (improvement BlenderCAVE). Later, we may work on integrating inside Blender this feature. Regards Damien On 04/11/2011 21:36, Dalai Felinto wrote: Hi Damien, It's strange, I could swear I had replied to your post in the forum [1]. I have been in touch with Jorge Gascon for the BlenderCAVE project and he pointed me to your idea. For your patch the better place to put it is in the projects.blender.org website and post here the link. I'll be glad to look at your patch. What I've been thinking (and it may be a better topic for the tracker instead) is if it wouldn't be more interesting to really support caves. For example, to introduce in the interface the options required to setup the number of walls, the wall distance, ... But I never visited a cave so I don't know how standard the output from the visualization tools are. Anyways, an option to set individual projection matrixes per stereo eye seems good too. Cheers, Dalai [1] - http://www.blender.org/forum/viewtopic.php?p=90396 2011/11/4 PabloVazquez.orgvenom...@gmail.com: BTW, I just tried it live yesterday :) Here at Universidad Rey Juan Carlos in Móstoles (Madrid), it was awesome, specially with 3D glasses, still some little things to fix, but the overall experience is very rich, just needs cool graphics to make it more awesome! :) -- Pablo Vazquez CG Artist Blender Foundation Certified Trainer E-mail: cont...@pablovazquez.org Website: http://www.pablovazquez.org On Fri, Nov 4, 2011 at 17:32, Ton Roosendaalt...@blender.org wrote: Hi, Interesting stuff! I'll make sure our dome/vr guru Dalai Felinto will check on it :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 4 Nov, 2011, at 14:32, Damien Touraine wrote: Hi, I'm working on the BlenderCAVE project (http://www.gmrv.es/~jgascon/BlenderCave/). Its purpose is to use blender to render on CAVE systems (http://en.wikipedia.org/wiki/Cave_Automatic_Virtual_Environment). We use python API to synchronize the scene across all computers that render on a screen. Python API is also used to adapte the camera to the current screen (ie : the one that is attached to the current computer). For this feature, it is important to be able to define precisely the projection matrices for both eyes independently. More specically, we must be able to adapt the projection to the right position of the user eye. For instance, you can to turn on yourself while looking on the floor screen. With default stereocopy viewing mode of BGE the eyes of the user must stay parallel to the screen and horizontal. Although we have searched, we haven't found any way to define projection matrix for left eye independently from right eye through the python API. Thus, we suggest a patch we have developped. This patch creates two projection matrices (left and right eye) besides the current one for a given camera. It manages the rendering for daily use (ie.: outside BlenderCAVE project). I can send the patch that is
Re: [Bf-committers] Blender tangent space calculation
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 it very hard to generate those tangents using Morten's
implementation directly in program, but think it'll be more a.. consistence
and ease way for people who building their games to properly export their
meshes :)
Maybe if nobody wants, then I'd like to try implement this by some time.
What you guys think about this?
Eugene
On Mon, Nov 14, 2011 at 2:41 AM, Eugene Minov minov@gmail.com wrote:
Oh, my bad :) I've seen that page but I'd thought this page is explains
different baking modes in blender's render.
Morten Mikkelsen - thank you for your great implementation! I'will learn
it!
M.G. Kishalmi - thanks for explanation )
On Mon, Nov 14, 2011 at 1:55 AM, M.G. Kishalmi l...@kishalmi.net wrote:
Eugene,
the link Morten pointed you
to
http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps
explains
that
the tangent space you created your normal maps in (in blender)
is generated by the implementation in
mikktspace.h
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/mikktspace/mikktspace.h
and
mikktspace.c
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/mikktspace/mikktspace.c
.
you might want to use those in your app (check the licence inside).
cheers,
lmg
On Sun, Nov 13, 2011 at 10:51 PM, Eugene Minov minov@gmail.com
wrote:
Wow!! Thanks a lot, for pointing me to the google ;)
But I afraid that maybe I've not correctly describe my problem. If so,
sorry for that, because my english is still kinda weak.
My problem not in generating a normal maps (a textures) in blender. Not
at
all.
My problem is that I cannot fully correct render my already generated
normal maps in my app. Because, how I mentioned in the last mail, the
usual
methods for this purpose (by UV coords) is not gives me desired results.
So I wanted to ask for help with information about methods blender uses
for
generating tangents.
And yes, I had searched in google but unfortunately have't found
something
helpful yet.
If someone can point me to that kind of info, I will be very grateful!
On Mon, Nov 14, 2011 at 12:08 AM, Morten Mikkelsen
mikkels...@gmail.com
wrote:
There you go buddy -- http://lmgtfy.com/?q=blender+tangent+space
On Sun, Nov 13, 2011 at 8:46 AM, Eugene Minov minov@gmail.com
wrote:
Hi.
I am sorry if I subscribe into a wrong place, I am new and I've not
actually planned to change or to debug the blender sources yet.
But I trying to write app that'll be render models with normal
mapping
exported from blender, and I have a question about how exactly is
blender
calculates a tangent vectors when Unwrap operation in the editing
mode
performs?
Calculating tangents in my app in usual manner (using UV coords and
verts
positions) gives me different tangents for each face of the same
vertex
indexed from, and thus crumpled normal map looking.
Then by looking into blender sources (searching by 'tangent'
keyword)
I've
found a couple of functions with tangents calculations, like:
float axis[3] = {0.0f, 0.0f, 1.0f};
cross_v3_v3v3(tangent, normal, up);
normalize_v3(tangent);
After I tried same method in my program I've gotten almost perfect
looking
model, depending on what initial axis I've used.
To choose, which axis to use (0, 0, 1), (0, 1, 0) or (1, 0, 0) for
each
normal, I calculate max dot product of tangent calculated by each
axis
with
tangent calculated from UV coords.
But still it seems that in some rare vertices tangent is calculates
wrong,
maybe because of wrong initial axis.
So, can anyone please give me any information about tangents
calculation
formula that blender uses while generates UV coords or some advice
about
choosing initial axis.
Thanks for help.
Eugene
___
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 mailing list
Re: [Bf-committers] Why was BLENDER_VERSION_CHAR cleared?
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 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 that the newer version becomes not installable. Please keep BLENDER_VERSION_CHAR until 2.61 release! -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Why was BLENDER_VERSION_CHAR cleared?
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 If we use 2.60+svn41834 for svn snapshot after 2.60a, the package system incorrectly downgrade it to 2.60.1 (= 2.60a). 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 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 that the newer version becomes not installable. Please keep BLENDER_VERSION_CHAR until 2.61 release! -- IRIE Shinsuke ___ 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] Why was BLENDER_VERSION_CHAR cleared?
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, 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 If we use 2.60+svn41834 for svn snapshot after 2.60a, the package system incorrectly downgrade it to 2.60.1 (= 2.60a). 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 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 that the newer version becomes not installable. Please keep BLENDER_VERSION_CHAR until 2.61 release! -- IRIE Shinsuke ___ 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] Blender tangent space calculation
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 mirrored UVs and saving the polarity in the 4th
component, just like blender's generated GLSL code expects.
2011/11/14 Eugene Minov minov@gmail.com:
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 it very hard to generate those tangents using Morten's
implementation directly in program, but think it'll be more a.. consistence
and ease way for people who building their games to properly export their
meshes :)
Maybe if nobody wants, then I'd like to try implement this by some time.
What you guys think about this?
Eugene
On Mon, Nov 14, 2011 at 2:41 AM, Eugene Minov minov@gmail.com wrote:
Oh, my bad :) I've seen that page but I'd thought this page is explains
different baking modes in blender's render.
Morten Mikkelsen - thank you for your great implementation! I'will learn
it!
M.G. Kishalmi - thanks for explanation )
On Mon, Nov 14, 2011 at 1:55 AM, M.G. Kishalmi l...@kishalmi.net wrote:
Eugene,
the link Morten pointed you
to
http://wiki.blender.org/index.php/Dev:Shading/Tangent_Space_Normal_Maps
explains
that
the tangent space you created your normal maps in (in blender)
is generated by the implementation in
mikktspace.h
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/mikktspace/mikktspace.h
and
mikktspace.c
https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/mikktspace/mikktspace.c
.
you might want to use those in your app (check the licence inside).
cheers,
lmg
On Sun, Nov 13, 2011 at 10:51 PM, Eugene Minov minov@gmail.com
wrote:
Wow!! Thanks a lot, for pointing me to the google ;)
But I afraid that maybe I've not correctly describe my problem. If so,
sorry for that, because my english is still kinda weak.
My problem not in generating a normal maps (a textures) in blender. Not
at
all.
My problem is that I cannot fully correct render my already generated
normal maps in my app. Because, how I mentioned in the last mail, the
usual
methods for this purpose (by UV coords) is not gives me desired results.
So I wanted to ask for help with information about methods blender uses
for
generating tangents.
And yes, I had searched in google but unfortunately have't found
something
helpful yet.
If someone can point me to that kind of info, I will be very grateful!
On Mon, Nov 14, 2011 at 12:08 AM, Morten Mikkelsen
mikkels...@gmail.com
wrote:
There you go buddy -- http://lmgtfy.com/?q=blender+tangent+space
On Sun, Nov 13, 2011 at 8:46 AM, Eugene Minov minov@gmail.com
wrote:
Hi.
I am sorry if I subscribe into a wrong place, I am new and I've not
actually planned to change or to debug the blender sources yet.
But I trying to write app that'll be render models with normal
mapping
exported from blender, and I have a question about how exactly is
blender
calculates a tangent vectors when Unwrap operation in the editing
mode
performs?
Calculating tangents in my app in usual manner (using UV coords and
verts
positions) gives me different tangents for each face of the same
vertex
indexed from, and thus crumpled normal map looking.
Then by looking into blender sources (searching by 'tangent'
keyword)
I've
found a couple of functions with tangents calculations, like:
float axis[3] = {0.0f, 0.0f, 1.0f};
cross_v3_v3v3(tangent, normal, up);
normalize_v3(tangent);
After I tried same method in my program I've gotten almost perfect
looking
model, depending on what initial axis I've used.
To choose, which axis to use (0, 0, 1), (0, 1, 0) or (1, 0, 0) for
each
normal, I calculate max dot product of tangent calculated by each
axis
with
tangent calculated from UV coords.
But still it seems that in some rare vertices tangent is calculates
wrong,
maybe because of wrong initial axis.
So, can anyone please give me any information about tangents
calculation
formula that blender uses while generates UV coords or some advice
about
choosing initial axis.
Thanks for help.
Eugene
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
Re: [Bf-committers] Why was BLENDER_VERSION_CHAR cleared?
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 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, 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 If we use 2.60+svn41834 for svn snapshot after 2.60a, the package system incorrectly downgrade it to 2.60.1 (= 2.60a). 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 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 that the newer version becomes not installable. Please keep BLENDER_VERSION_CHAR until 2.61 release! -- IRIE Shinsuke ___ 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] Collada and Custom Properties export
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 that would *greatly* benefit from this feature (so I could use Blender as a level editor for graphics, physics and so on). I would like to know if this will be implemented in the very near future or not. I have experience and feel confortable enough with C++ that I think I could help implement this support if someone gives me a little guidance on where to look (something more than the collada folder). Thanks. -- Micael Dias ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-cycles] Dithering in preview mode
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 a comparison of the shading on a sphere, without dithering, with the new method and the old method (in that order): http://www.pasteall.org/pic/show.php?id=20732 (levels exaggerated in compositing) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender tangent space calculation
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 access to the unconditionally averaged/smooth normals at the vertices. Ie. the api doesn't take faces set to soft/hard into account when submitting normals back to the script. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Why was BLENDER_VERSION_CHAR cleared?
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 little more bulletproof when
dealing with other fedora repos...
Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Why was BLENDER_VERSION_CHAR cleared?
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.60a, b, c --- are meant for release titles, but don't effect the
source and are not stored in the blend file.
the reason the character is converted into a number is that some
package formats don't support characters - '2.60a' as a version
number, but it does become confusing with BLENDER_SUBVERSION which
gets used in a similar way.
so can see its a bit confusing but prefer to keep this as is.
On Tue, Nov 15, 2011 at 4:36 PM, Dan Eicher d...@trollwerks.org wrote:
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 little more bulletproof when
dealing with other fedora repos...
Dan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
