[Bf-committers] Interest in GSoC 2010 topics: 1. "Integrate PTex texture mapping library" 2. "Unit tests"

[Konrad Wilhelm Kleine]

Hi LetterRip,

> Konrad your proposal sounds good but as you note you will need a bit
> more details on schedule.

Thank you! I'm working on the missing parts of my proposal ;)

> Something to consider if it isn't in the library already is dynamic
> loading and unloading of level of detail textures.  

You are right. As I understand from this mailing list entry, loading and
unloading and textures on demand is done by Ptex on the CPU side but NOT
on GPU side
(http://groups.google.com/group/ptex/browse_thread/thread/d518f72a9792a2fd).
But this could be expected, I guess. Handling textures on the GPU
involves either some kind of rendering context (i.e. OpenGL or Direct3D)
which is normally handled by the application that wants to integrate Ptex.

> That is, say the total texture resolution of the model would consume ungodly amounts of
> ram, drastically more than your computer is capable of.  So instead of
> keeping all of the texture in memory at once, when a face is far away
> from the brush, the texture is unloaded from ram, and a low res proxy
> is put in its place - and/or for areas that the brush is far away
> from, the view render of the texture is kept and the real part of the
> texture is offloaded, and the texture changes are kept in view space
> until they are reprojected onto the mesh (which can be done threaded
> in parallel or such).  So you could have ridiculously sized textures,
> bigger than your computer would normally every be able to handle, and
> handle them in real time with ease.

That would be nice, indeed. On the other hand, consider Blender's
sculpting tool and how much effort and time needed to be invested in it
to make it more memory efficient. That said I think that intelligent
"texture garbage collection" should not be part of the GSoC project.

Please, let me explain why I think so:

A working Ptex integration that handles fit-in-you-(G)RAM textures is
possible better than a broken and over engineered integration. I think
so because I want to keep the life cycle of development and user
feedback as short as possible. The earlier artists can experiment with
the Ptex integration, the earlier they will demand features and
improvements. Maybe to them it is more important to elaborate the brush
system at first instead of increasing the maximum texture size. Who knows?

Do you agree with me?

For now my first deliverable is going to be a Ptex file viewer for the
UV/Image editor. This way I get to know the Ptex file format more.

Konrad