Only if you don't accidentally head in direction of the sun ;-)
Am 02.03.2011 09:09, schrieb Luke Frisken:
> Things get blacker as you leave earth's atmosphere and head into space :)
>
> On 3/2/11, Knapp wrote:
>> On Tue, Mar 1, 2011 at 12:34 AM, Daniel Salazar - 3Developer.com<
>> zan...@gmail.c
Things get blacker as you leave earth's atmosphere and head into space :)
On 3/2/11, Knapp 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
>> side. Anyway I've done s
Can't think of any that don't contain the word "Blender" :)
On Tue, Mar 1, 2011 at 11:24 PM, Knapp 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
> > side. Anyway
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
> side. Anyway I've done some investigation and the other mainstream
> software I checked all use white for height an black for down.
>
> >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 cho
Hi,
The way it works now in Blender is just ancient convoluted history.
My idea would be to postpone such changes and do this together with a
decent redesign & makeover of the internal shader/light/texture system.
It's also about focus... let's try to get blender out of beta for 2.5
targets f
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:
right.. we could come up with a million analogies for one or the other
side. Anyway I've done some investigation and the other mainstream
software I checked all use white for height an black for down. We
could have a fix like the one they did for normal maps
cheers
Daniel Salazar
www.3developer.c
Wow, it seems like this is the rare issue where all seem to be in agreement!
Seems white = up, black = down. Though my word does not carry much weight
I would like to give a +1 to making it this way.
And I might as well throw my little analogy here - For bump mapping I always
thought of snow.
I vote for a yin and yang brush, activated by ctrl-clicking. :) No time for
a patch yet I'm afraid
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Guess so. Alone the fact that the mapping of white as peaks and black as
valleys is fairly similar to the actual shading result, makes it more
intuitive. Valleys are often inside the shadow as the deep sun touches
the mountain peaks. Pores of the skin are commonly darker then the rest
of it. ..
Sorry but could not resist.
Black is yin, white is yang.
wiki
'It is impossible to talk about yin or yang without some reference to the
opposite, since yin and yang are bound together as parts of a mutual whole
(i.e. you cannot have the back of a hand without the front). A way to
illustrate this
I asked around and apparently white is usually the peak and black the
hole in other software.. so from an integration perspective you are
right
Daniel Salazar
www.3developer.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blende
Same thought on my side. White is a high value. Why making a peak am
hole? Don't know any software that uses black for the tips of anything.
Gimp uses white as peaks for bump mapping and any other known graphic
software too. Even SVG-(Filters) define white as a high spot. At least
it is the def
I don't think it's irrelevant, it's more logic. IMHO black should be a
pit and white a hill. Black is absence, and white is presence.
On 25 February 2011 23:03, Daniel Salazar - 3Developer.com
wrote:
> Kinda irrelevant imo since its so easy to invert, maybe if someone can
> demonstrate that the m
I think black=crevice white=peak is the convention too. Most(all?) of the
bump-mapping related papers I've seen are written on this premise.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Kinda irrelevant imo since its so easy to invert, maybe if someone can
demonstrate that the mayority of other software does it the other way
then you'd have a point since it would simplify sharing from one
software to another.. a tiny bit
cheers
Daniel Salazar
www.3developer.com
2011/2/25 Joll
I certainly think that it would be preferable to have this changed,
especially when the displace modifier works the opposite way.
I noticed this when porting the old tile texture to 2.5
___
Bf-committers mailing list
Bf-committers@blender.org
http://list
> On Thu, Feb 24, 2011 at 10:03 PM, Morten Mikkelsen
> wrote:
> > So as you guys most likely know white means down and black means up when
> > bump mapping in Blender
> > which is kinda counter intuitive.
[SNIP]
>
> Is there a 'standard' - ie does every other 3d animation package use
> the invers
I have attached a proposal for a patch.
I put in a comment as well.
On Fri, Feb 25, 2011 at 6:29 AM, Morten Mikkelsen wrote:
> It would be extremely easy to fix this for just the most recently added
> bump mapping
> method should we choose to do it that way.
>
>
>
> In render_texture.c in the f
It would be extremely easy to fix this for just the most recently added bump
mapping
method should we choose to do it that way.
In render_texture.c in the function ntap_bump_compute() At the top
change the line:
float Hscale = Tnor*mtex->norfac;
such that it's negated:
float Hscale = -Tnor*mtex
In pretty much everything out there the convention is "white is True,
black is False"...
in most DCC this equates to white being high (a bump) and black being
low(a crevice)...see lightwave, 3ds max, maya and also note that this
is consistent with the displacement map modifier in blender...
Is there a 'standard' - ie does every other 3d animation package use
the inverse of what we currently use?
LetterRip
On Thu, Feb 24, 2011 at 10:03 PM, Morten Mikkelsen wrote:
> So as you guys most likely know white means down and black means up when
> bump mapping in Blender
> which is kinda cou
So as you guys most likely know white means down and black means up when
bump mapping in Blender
which is kinda counter intuitive.
However, we recently did a completely new implementation of bump mapping for
Blender
and I was wondering, since we kept in the original bump mapping methods
as availabl
24 matches
Mail list logo
