2.6

Revision: 44256

Author: campbellbarton

Log Message:

-----------

BMesh Merge

===========

initial merge from BMesh branch,

this replaces the existing mesh format and editmode data structures, for more info see:

http://wiki.blender.org/index.php/Dev:2.6/Source/Modeling/BM...

this is the work of quite a few developers over the years.

Key Contributors

================

* Geoffrey Bantle (aka) Briggs, original author.

* Joe Eager (aka) joeedh

More recently

* Howard Trickey

* Ender79 aka Ender79

What to Expect

==============

In general blender shouldnt crash on files or totally fail to load scenes,

painting tools etc have been tested to work.

* its quite easy to make the tesselator fail (show holes, missing faces), with non planer ngons.

* most modifiers are working fine but a few had to be re-written - bevel, array - array is much slower, bevel will probably be changed to match trunk soon.

* NavMesh BGE feature isn't functional yet.

* Some UV sticth tools still need porting.

* hair doesnt work right on ngons yet.

* many python scripts will break.

* a python api to BMesh needs to be written still.

(for todo's in code do a searh for BMESH_TODO)

Just a quick update to show we're making some progress here. We got a

new OpenCL runtime to test from AMD (with fixes which will presumably

be in the next driver release), and for the first time we now got

shading nodes and textures working, which puts this at feature parity

with GTX 2xx cards using CUDA.

The main issue with this still is that compiling uses a lot of memory

(about 6GB when I tested). It's possible to build these in advance and

bundle them as we do for CUDA, so we'll look into getting that set up.

Brecht.

Author: alexk

Date: 2012-03-20 02:17:37 +0000 (Tue, 20 Mar 2012)

Log Message:

-----------

Adds support for utf paths on Windows.

Compositing View Port Proposal

This year I am considering proposing a new viewport for Blender as a

Summer of Code project.

Name is subject to change. I've already had one person think that I

want to preview compositing nodes in the view port. That is not my

proposal.

This email is to solicit some feedback so that I can write a good

proposal or change my focus and propose something else.

The problems as I currently see them:

* The current view port rendering code in Blender is a mess.

* Extending the view port has to be done ad hoc and is even

recommended against due to its complexity

* Taking advantage of modern opengl features might be especially

difficult. These include:

- pixel buffers

- floating point or HDR formats

- depth textures

Parts of a possible proposal:

* re-factor all view port drawing operations into a set of composable commands

* enable rendering to pixel buffers

* compose pixel buffers using GLSL and/or blending operations

* new view port modes can be written as scripts, like Render Monkey or

DirectX Effect format (or even Quake 3 if you wanna go back that far)

* re-enable all current view port modes as just simple scripts in the new system

* create new view port modes (like Material Capture or SSAO)

* let expert users create their own custom viewports

* the ability to control view port script parameters using RNA, i.e.,

automatically add controls to the UI

I am not proposing doing anything with the GLSL code generator that is

used for materials.

I have not looked into how this integrates with the different view

port drawing modes (triple, etc.)

I am concerned that PBVH drawing in 'partial redraw' mode may be more

difficult to integrate, or not.

Cursor rendering probably is not affected.

I discussed this briefly with Ton, he had some ideas about glowing

outlines around objects. That kind of feature would be possible.

Part of my proposal could include a set of example view ports scripts

like that to get the expert users started.

I'd like to really focus this year on a single goal with an easily

defined deliverable.