[Bf-committers] Texture synthesis node

[Vilem Novak]

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>
> 
> 
>