I see rumblings now and then here and there about Blender's
python API missing the ability to export Blender's internal tangent space.
http://www.blender.org/forum/viewtopic.php?p=105835sid=68eaa02463462a62bbdcbe427761ca49
There's also been a proposed patch around for a while:
I just wanted to say I think that sounds like a great idea.
Cheers,
Morten.
On Sat, Aug 10, 2013 at 10:26 AM, Antony Riakiotakis kal...@gmail.comwrote:
Either make the strokes touch mesh data directly, or use an apply base
modifier prior to baking, maybe with a warning that baking will
This could be done of course but there are some problems like the fact that
the object space map doesn't necessarily come from file.
It could be procedurally generated or just a bake in which case the sampler
isn't supposed to swizzle.
Also the texture sampler at least at this point in time
Good idea. Let's drop VS2008 :)
Cheers,
Morten.
On Sun, Mar 17, 2013 at 3:32 AM, Thomas Dinges blen...@dingto.org wrote:
Hi,
I was never a fan of those mixed repositories, and the few vc2010 libs
we have only work with cmake as well.
Whatever we do, one day we really need to get rid of
Errr...I actually use msvc2010.
Whatever contributions I've made to blender have been from a vs2010 setup.
It's still how I build blender.
On Fri, Mar 15, 2013 at 4:28 PM, Dalai Felinto dfeli...@gmail.com wrote:
Hi, is there any update on this?
If we can't have all the libs working for
That's ok, as long as you admit that you were wrong :)
(kidding)
On Mon, Mar 4, 2013 at 7:02 AM, Antony Riakiotakis kal...@gmail.com wrote:
My previous answer is wrong it seems. It looks like when using the
space stroke option, the two modes (projective/2D) operate slightly
differently.
Go for it! :)
On Sun, Mar 3, 2013 at 7:01 PM, Antony Riakiotakis kal...@gmail.com wrote:
This is trivial but will require yet another version patch. If others
agree I could commit it wit h a value of 16.
___
Bf-committers mailing list
Perhaps you could also look into why the default brush looks so bad for
bump painting yet when air-brush is checked it looks perfect.
Just a though :)
Cheers,
Morten.
On Sun, Mar 3, 2013 at 6:17 PM, Antony Riakiotakis kal...@gmail.com wrote:
Hi all, an update on this thread.
Sergey did a fix such that the dilated region outside a displacement map
isn't very dark.
Without it you get really bad filtering seams. Perhaps sergey can chime in?
Cheers,
Morten.
On Sat, Mar 2, 2013 at 2:47 AM, Dalai Felinto dfeli...@gmail.com wrote:
Hi Campbell,
Due to some bad
I agree completely. I think the default of 2 might have been set by someone
who
didn't take mip levels into account. To be honest I generally use 32 or 64
as margin
depending on texture size (larger texture means more mips).
But I suppose 16 as default which I think is also what it is in xNormal
Just wanted to say though I'd like to make it a min. requirement for
blender to support pixel shaders
last I checked I wasn't kickin it with the Rockafellas :)
I also want to echo what campbell said that blender runs very well on sub
$500 systems which btw support pixel shaders.
I also want to
I just wanted to say that I too agree that we should assume some higher
level opengl.
I think it would be rather helpful in fact if we didn't rely on traditional
fixed function rendering period
but instead keep it simple such that we're always using custom shading. It
keeps it simpler,
easier to
If development is being held back by attempting to support old hardware
and OS versions and no one is willing to step up and support those bits
then their use should be depreciated.I would much rather see the limited
developer hours available put towards moving Blender forward rather than
Doesn't matter if it's win32 or win64. Either way the pyth3.3 libs are
missing for vs2010.
On Wed, Dec 19, 2012 at 11:15 AM, Dalai Felinto dfeli...@gmail.com wrote:
New round of errors: http://www.pasteall.org/38201
It's actually the same as before but instead of complaining about LIB
/scripts/addons/io_scene_obj/export_obj.py
Am 14.11.2012 21:31, schrieb Morten Mikkelsen:
The important thing is that any proposed solution will work with export
too.
If the obj exporter is still exporting quads and beyond then this is not
a
solution.
The modifier solution will make sure
[...] - Morten Mikkelsen
There shouldn't be manual triangulation, as export scripts can use
tessfaces to get triangulated geometry. Maybe here's the inconsistency?
The Triangulate Faces operator (former Quads to Tris) might create
triangles different from the tessfaces. I wonder how
When baking with an all quad mesh, the triangulation that is done
internally in Morten's TS might not match the manual triangulation that
the user applies on export, which potentially could cause issues because
This is not exactly the issue. Let me clarify.
The mikktspace part is done at
For aniso lighting computing tangents at vertex level is a total dead-end.
Not the way to go.
You want to compute the tangents at pixel level from the underlying
parametrization chosen.
It's the best way to significantly reduce the impact of the inherent
singularities which completely destroy the
In case it's not clear. What I am saying is for actual uv unwraps use
mikktspace.
For a UV parametrization such as planar, cylindrical, spherical etc. use an
analytical
tangent evaluation at pixel level.
On Thu, Oct 11, 2012 at 12:44 PM, Morten Mikkelsen mikkels...@gmail.comwrote:
For aniso
Ok, I can see we have an issue with singularities, but using
mikktspace does not seem ideal for anisotropic shading. There's still
many cases where you can line up the tangents quite well at UV seams
even if the UV's are not connected,
Generally this is not the case. It goes bad at least
a seam between them too.
Brecht
On Tue, Oct 16, 2012 at 8:34 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
Ok, I'm still convinced we can do better than either, will try to figure
it out.
Can't blame a man for trying :)
Food for thought though:
http://en.wikipedia.org/wiki
Roosendaal Blender Foundation t...@blender.orgwww.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:
1) Official announcement that Blender drops Collada support
2) Move Collada support into a branch, out
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 Mikkelsen mikkels...@gmail.com
wrote:
Yes that's a very relevant point. A collada solution with just positions,
UVs and normals
As an example of people having problems with its complexity OpenCollada
doesn't drain collada sources correctly at all.
They make many assumptions such as data being non interleaved.
On Sat, Jan 7, 2012 at 8:23 AM, Juan Linietsky redu...@gmail.com wrote:
On Fri, Jan 6, 2012 at 9:04 PM,
that loads a
.blend
file,
extracts textures, meshes, animations, skinning and physics info.
It shows a skinned skeletal animated character using AnimKit and GLUT
(keeping dependencies to a minimum)
Cheers,
Erwin
On 7 January 2012 07:38, Morten Mikkelsen mikkels
I acknowledge that the amount of work you guys have put into OpenCollada is
significant and I am definitely pleased with
this as an option. That being said I am beginning to warm up to what sergei
is suggesting more and I am actually a collada user myself.
Correct me if I am wrong but the way it
Okay I guess you did misunderstand my misuse of the word crappy.
What I meant was more like less likely to work with existing OpenCollada
importers. Those which are already used in other apps.
Clearly an OpenCollada exporter is more likely to work with an OpenCollada
importer
across apps. This was
I agree Marty. It's awesome. Give my best to the doc! :)
On Sat, Jan 7, 2012 at 2:29 PM, Michael Fox mfoxd...@gmail.com wrote:
On 08/01/12 08:28, angjmi...@gulftel.com wrote:
hey i am hearing that your planning on removing collada!!
i know there is a lot of issues with it but, at-least as
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).
I just want to say though I am not up for the challenge of taking over
I agree, I could also live with ditching the importer if it meant keeping
the exporter.
But either way I'll take current collada version to no collada version at
all.
On Fri, Jan 6, 2012 at 5:11 PM, skoti skot...@o2.pl wrote:
Assimp only importer (exporter in blender is the most important),
it by swapping the first vertex in the vert
array with
the first finded vertex that is not indexed to any of the 4'th face's
index.
On Sat, Nov 19, 2011 at 1:13 AM, Morten Mikkelsen mikkels...@gmail.com
wrote:
I wanted to ask about this line:
const int iGetNrVerts= data-mface
to the indices you get after welding.
On Sat, Nov 19, 2011 at 12:35 PM, Morten Mikkelsen mikkels...@gmail.comwrote:
I am not 100% sure I understand you correctly but your fix doesn't sound
correct but perhaps
I am misunderstanding you. Anyway, the welder is going to generate a zero
based index
I wanted to ask about this line:
const int iGetNrVerts= data-mface[face_num].v4!=0 ? 4 : 3;
Or there is no way that last index points to zero?
Correct, this is how blender does it everywhere in its code-base.
Super glad to hear you're getting useful results! Be sure to submit a patch
for
, Nov 16, 2011 at 8:43 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
Sorry for confusing you here but I think I found a better reference for
you
since
you'll be needing the tangents too and you are not supposed to be
building
them yourself.
The proper way to get the tangent layer can
And flush_pixel() shows you how to traverse the buffer.
Essentially the way it works in blender is there's always 4 of them
per face whether it's a triangle or a quad.
On Thu, Nov 17, 2011 at 9:31 AM, Morten Mikkelsen mikkels...@gmail.comwrote:
Don't forget to look in do_multires_bake
to implement it looking in DerivedMesh.c,
I think that it's realy are a good example.
If or when I have a problem, I'll be glad to use your help :)
Many thanks for your kind cooperation!
On Tue, Nov 15, 2011 at 10:41 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
I don't know anything about
There is no point in doing this unless you export the correct tangents and
normals. That is the ones
that were used to bake the normal map.
I realize it blows that there is no API function to get the render normal.
So what you have to do is produce it yourself
like is done in
wrote:
Yes, I absolutely agree, hard faces obviously must be exported in the same
way how they seen in render.
I think they can welds along with tangents.
On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
There is no point in doing this unless you export
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
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
can
work this in somehow.
Several artists were bugged by the lack of quality during close-up when
painting bump maps.
2011/10/26 Αντώνης Ρυακιωτάκης kal...@gmail.com
Hi everyone, there has been some work by Morten Mikkelsen for
supporting bicubic filtering for bump maps. I have helped
available for the chosen file format
such as bit depths and number of channels or something.
Cheers,
Morten Mikkelsen
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Does this mean I get to demand more service from you? :)
Congratulations!
Morten :)
On Mon, Aug 1, 2011 at 9:21 AM, rafa rsaave...@ono.com wrote:
Congratulations Sergey !!
I wish you the best!
El 31/07/11 18:47, Ton Roosendaal escribió:
Hi all,
I'm really happy to confirm that
I am with you on this one. Memory layout is one thing. Abstraction is
something else entirely.
Afterall, one could choose the memory layout to be some crazy fixed random
layout or a swizzled
layout or whatever. And in both cases there is no reason why, at abstraction
level, either one could be
other apis do it ROW-MAJOR
then perhaps?
Interested to hear other blender devs opinions on this.
On Wed, Jul 27, 2011 at 11:56 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
I am with you on this one. Memory layout is one thing. Abstraction is
something else entirely.
Afterall, one
other apis do it ROW-MAJOR
then perhaps?
Interested to hear other blender devs opinions on this.
On Wed, Jul 27, 2011 at 11:56 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
I am with you on this one. Memory layout is one thing. Abstraction is
something else entirely.
Afterall
The dilation I am seeing in Blender is imo not good. I thought I'd propose
an alternative (if there's support)?
Here's a close-up of the dilation blender does --
http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png
Here's a close-up of the dilation I was able to do outside of blender using
You should read the posted comments there under that tutorial.
Cheers,
Morten.
2011/7/7 Αντώνης Ρυακιωτάκης kal...@gmail.com
Recently, this tutorial http://vimeo.com/19461966was brought into my
attention which made me wonder if it would be possible to automate the
process of applying the
Could it be that Cinema4D is using Phong-Shading and Blender is using
Gouraud-Shading?
Yes that's exactly what you're seeing. You can switch to glsl view if you
want to view it in Blender with per pixel lighting.
Regular 3D view has to remain fixed function rendering pipeline which
implies
Also a lock camera to view option would be great so we can just move
the camera like we move any other viewport
am I the only one that doesn't get this?
This is something I would absolutely LOVE to have!!
I couldn't agree more. It would be mega helpful.
The way it works now in Blender is just ancient convoluted history.
My understanding is that with oldbump (2.49) it never really worked?
Meaning it would flip the effect from in to out and vice versa as you
bank/rotate the surface relative to the camera right?
In which case a consistent choice
Can't think of any that don't contain the word Blender :)
On Tue, Mar 1, 2011 at 11:24 PM, Knapp magick.c...@gmail.com wrote:
On Tue, Mar 1, 2011 at 12:34 AM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
right.. we could come up with a million analogies for one or the other
Just want to make sure everybody realizes I already attached my proposal for
a patch in my previous e-mail to this
discussion. There's also a comment I put in on why etc. Please check it out.
Morten.
On Mon, Feb 28, 2011 at 3:34 PM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
Make it standard please, nmaps are something that you usually share
between softwares. no point in forcing headaches to users
Daniel Salazar
May your first born be a son and may your harvest be plentiful!! :)
I could not agree more. That's exactly why this patch needs to go in asap.
Normal
down, but after about
an hour of digging have given up.
-Sean
On Tue, Feb 22, 2011 at 12:26 PM, Morten Mikkelsen mikkels...@gmail.com
wrote:
Make it standard please, nmaps are something
that you usually share
between softwares. no point in forcing
headaches to users
Hi all,
Blender is exporting normal maps with red and green channel inverted
relative to the geometry we actually export with our exporters
and I would very much like to fix this. This would make blender export
normal maps which are very similar to most tools out there and it would make
sense to
, Carsten Wartmann c...@blenderbuch.de wrote:
Am 19.02.2011 16:22, schrieb Morten Mikkelsen:
Hi all,
Blender is exporting normal maps with red and green channel inverted
relative to the geometry we actually export with our exporters
and I would very much like to fix this. This would make
57 matches
Mail list logo
