[Bf-committers] Texture synthesis node

[Aurel W.]

Hi

Brecht,
> An approach like graph cut textures won't work well as a texture node
> though, since a texture node has to be able to get color values from
> just an x/y/z coordinate, there isn't a 2D image in which you can
> precompute the texture. It's possible get some methods to behave just
> like procedural textures however. Also possible is to just bake it
> into an image, taking into account UV's to make it seam free.
Well, yes, a simple texture synthesis node would take a pixmap as an
input and outputs a larger pixmap. So this would be sort of equivalent
to the current image input texture node. With graphcut for e.g. you
can also make tileable images, so you could precompute a simple image
buffer and evaluate a texture at any coordinates from this without
seams.

But as Keith mentioned, there are already two plugins for GIMP which
do texture synthesis and I guess there won't be real benefits from
integrating this into blender except from maybe a slightly faster
workflow. Also a really performant and good implementation of graphcut
is more than just a task for the weekend.

Synthesis for real meshes and taking UV's into account is of course a
different story and I guess this would be quite useful.

Aurel

2009/6/25 Vilem Novak <pildanovak at post.cz>:
> Added since we wrote a mail at same time:
>
> I wrote my mail about compositor, while here you speak about texture nodes.
>
> I didn't much understand the discussion about filters e.t.c. on texture data,
> since without inventing these filters for 3d and loosing a lot of performance(much more sampling),
> these operations are simply not possible(just summing what was already said).
> But  of course the image isn't texture, the image is the input for the texture of class image. The naming is confusing :)
> If the image itself could become a node of a different type, it could get linked as input to the texture-image, and
> any filters - nodes from compositor could get applied on the way.
> Processing of such filters would have to be done before actual rendering.
> This of course goes on the cost of memory and performance, since whole
> images would get always processed, even if a small part of the texture can
> be actually seen in the render. Memory issues and repeated computation
> could get solved with caching the images on the disc.
>
> However, I like much more the idea of having a separate tree for anything to do with images - the compositor.
> For the 'preparation' phase of any textures, an input to image data block from compositor would be great.
> Now, if you do process an image in the compositor (blur/sharpen texture, color correct....) you have to save and reload it
> to see results in the 3d scene. If there would be an output node called 'imageblock', the preview would be interactive.
> Only problem I see again is - breaking the walls of what the compositor is considered to be for, and possible crazy
> circular dependencies. But I guess not many artists would have the idea of linking render output to a texture in the same scene?
> if yes, then they would get what they deserve... :)
>
> Cheers,
> Vilda
>
>
>
>> ------------ Původní zpráva ------------
>> Od: Brecht Van Lommel &lt;<a href="mailto:brecht at blender.org">brecht at blender.org</a>>
>> Předmět: Re: [Bf-committers] Texture synthesis node
>> Datum: 25.6.2009 01:55:48
>> ----------------------------------------
>> Hi,
>>
>> I think texture synthesis is definitely useful for 3D software,
>> synthesizing over surfaces or over 3D volumes doesn't fit well in
>> image editing software.
>>
>> An approach like graph cut textures won't work well as a texture node
>> though, since a texture node has to be able to get color values from
>> just an x/y/z coordinate, there isn't a 2D image in which you can
>> precompute the texture. It's possible get some methods to behave just
>> like procedural textures however. Also possible is to just bake it
>> into an image, taking into account UV's to make it seam free.
>>
>> There's many papers about texture synthesis, these are some of the
>> best I think, perhaps Keith had one of these in mind:
>>
>> Parallel Controllable Texture Synthesis
>> Appearance-Space Texture Synthesis
>> Lazy Solid Texture Synthesis
>>
>> <a href="http://www-sop.inria.fr/reves/Sylvain.Lefebvre/">http://www-sop.inria.fr/reves/Sylvain.Lefebvre/</a>
>>
>> Brecht.
>>
>> Tyler Tricker wrote:
>> > I think image editing features should be left to dedicated image software
>> > packages like gimp.
>> >
>> > On Wed, Jun 24, 2009 at 7:06 AM, Wahooney &lt;<a href="mailto:wahooney at wahooney.net">wahooney at wahooney.net</a>> wrote:
>> >
>> >> There is a plugin for GIMP that does this sort of thing very well, in
>> >> fact it's based on the paper that you've linked to. So for this
>> >> technique external may be better.
>> >>
>> >> However, a better idea would be another technique that maps the texture
>> >> straight to the mesh, I read about it a few years ago. It's very robust
>> >> and the results are quite amazing. I'll look for the paper and post it
>> >> here when I find it.
>> >>
>> >> Keith
>> >>
>> >> Aurel W. wrote:
>> >>> Hi,
>> >>>
>> >>> I was wondering if texture synthesis from images would be of use in
>> >>> texture nodes, or if it's better not to integrate this and do it with
>> >>> external tools. Implementing
>> >>> <a href="http://www.cc.gatech.edu/cpl/projects/graphcuttextures/">http://www.cc.gatech.edu/cpl/projects/graphcuttextures/</a> may be a good
>> >>> option. Depending on the type of algorithm and settings used,
>> >>> calculating such textures can take some time and I am concerned, if
>> >>> nodes which would take about 10-20 seconds or so to compute, still fit
>> >>> good into a node editor.
>> >>>
>> >>> What do you think, would this even be of use?
>> >>>
>> >>> Aurel
>> >>> _______________________________________________
>> >>> Bf-committers mailing list
>> >>> <a href="mailto:Bf-committers at blender.org">Bf-committers at blender.org</a>
>> >>> <a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a>
>> >>>
>> >>>
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> <a href="mailto:Bf-committers at blender.org">Bf-committers at blender.org</a>
>> >> <a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a>
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > <a href="mailto:Bf-committers at blender.org">Bf-committers at blender.org</a>
>> > <a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a>
>> >
>> >
>>
>> _______________________________________________
>> Bf-committers mailing list
>> <a href="mailto:Bf-committers at blender.org">Bf-committers at blender.org</a>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-committers">http://lists.blender.org/mailman/listinfo/bf-committers</a>
>>
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>