Amateurfilm-Forum

Zitat

The owner of Blender, NaN Holding BV, has decided on a definite new future for Blender. The independent non-profit organisation Blender Foundation will obtain a license to continue Blender development by publishing and maintaining the sources and make it 'free software' or 'open source' forever.
[...]

Zitat von »Nicholas Bishop«

And a surprising lack of UV coordinates as well.

For reference, total number of texels across the entire mesh is 66,501,632, which is equivalent to a 8155px by 8155px texture (assuming the texture was perfectly packed with no wasted space.)

This is ptex, of course. The implementation isn't complete, but here's what working for now:
* Per-face ptex resolution. Each face gets a U resolution and a V resolution based on its area (relative to other faces) and how stretched it is (i.e. a thin tall face should have a lower U resolution and a higher V resolution.)
* Automatic generation of ptexes. This step is somewhat analogous to unwrapping your mesh, except instead of choosing UV coordinates, it's setting the default ptex resolution for each face. There's a UI control for texel density.
* "Vertex" painting. That's a bit of a misnomer now, of course, but you can paint more or less normally. (Naturally I've broken some vpaint features like Blur in the process, but it'll all be restored.)

Note: ptex is designed mainly to work on quads. Triangles and other faces are split up into quads in the same manor as Catmull-Clark. I've coded it so that both quads and tris work (although there are some mapping issues with vpaint still), however quads are the "fast case"; for this reason I've applied one level of subsurf to Suzanne in this example.

A partial TODO list:
* Add UI for setting individual faces' resolutions
* Integrate the open source ptex library for loading and saving ptex files
* Add upsampling/downsampling so that changes aren't lost when changing ptex resolution
* Change default ptex to a flat color. The random noise is just for testing, of course

Zitat

[...]
Short term roadmap prediction:

- March: 2.57 release (with at least a week an RC for test)
Being our 'first' 2.5 official release, it could align with a make-
over of blender.org!
- April/May: 2.58 as final for the 2.5 project (based on 2.57 feedback?)

In May we then can move svn to 2.60, and start merging it with at the
urgent waiting branches;
- render branch (sintel)
- bmesh (how's it going?)
- GSoC projects, like rigid body anim

During the next months the branch devs can report here on how stable
migrations are, to make a planning that doesn't break 2.6 immediately,
but do this in smaller steps and releases.

I then would also like to start the recode for our shader system (in
branch at first)
And will have to wrap up the python api, especially for UI customizing
and render api.

Exciting times ahead,

-Ton-

• Real-time Vorschau im 3D-View während dem arbeiten möglich
  
• 100% Ray-based design
  
• Verwendet die Open Shading Language von Sony Imageworks
  
• Die Engine läuft auf der CPU oder GPU (CUDA, OpenCL (OpenCL noch nicht fertiggestellt))