Viewport FX

My proposal, Viewport FX, for Google Summer of Code was accepted this year. The goal of Viewport FX is to improve the performance and flexibility of the 3D viewport drawing code in Blender. This is known as the “3D view” internally.

The first goal, performance, is not meant to provide any additional end-user features. Which makes it difficult to figure out what I should tell you guys since you are mostly end-users and you want features :slight_smile: Performance is a nice feature to have though.

The second goal is more interesting from an end-user perspective because the idea is to make the 3D view configurable. By configurable I mean that instead of “wire”, “solid”, “texture”, etc. that you more modes could be added without having to learn C. Also, the existing modes would be built by using the basic features of the new system.

There are actually many more modes for the viewport than you can select because the different editing modes in Blender interact with the different drawing modes to produce quite a few different possible rendering paths.

To understand where I am going with this, it may be helpful to look at some previous examples of the kind of system I am looking to create:

FX Composer

Render Monkey
http://developer.amd.com/archive/gpu/rendermonkey/Pages/default.aspx

Direct3D .fx Files
http://msdn.microsoft.com/en-us/library/bb173002(v=vs.85).aspx

Quake 3 Shader Manual
http://www.heppler.com/shader/

I’d like to stress that a full end-user usable system is probably out of reach for one SoC. Refactoring the code for performance is the #1 priority. However I’d still like to have a discussion about the potential uses of a more flexible and configurable viewport. Beyond the editor this work has implications for the game engine or a fancy OpenGL renderer.

My personal motivation is that I wanted to add additional “visualization” modes to sculpt and paint, but I found the task of extending the current viewport to be too ad hoc. You guys might be able to think of other uses, and that would help me make sure I make the right decisions this summer so that I do this correctly.

Sounds awesome! Good luck to you jwilkins the faster and versatile 3D viewport drawing code the better.

No, no, a performance boost is very much needed, and I’d like to thank you for taking on this difficult and underappreciated task.

Besides sculpting shaders, one use I can think of is making a good view mode for retopologizing - one that lets you clearly see both the hipoly source mesh and the mesh you’re editing, and doesn’t suffer from the backfacing problem.

I do not mean to be overly humble about improving performance, it is just that the nuts and bolts of it are not something I’d expect the people on blender artists to be very helpful with. My main point is that I do not want to over promise on how much of the new infrastructure will be usable mere mortals by the end of the summer. The one thing I absolutely want to have improved by the end of the summer is performance.

Thanks for taking on this task! looking forward to the progress…

Just a question, are you looking at allowing python based FX to plug into the system? (that could be coded from within blender?)

If not, im sure i’ll check out the source code :slight_smile:

cheers again!

At this point I am not sure exactly how the functionality will be exposed. Python seems like a reasonable way to do it. I was also thinking of using COLLADA or some custom text as the interchange format. Some kind of node based editor is too much to think about for now :slight_smile:

I’m looking forward to it - good luck!

In another thread I saw a suggestion that Blender’s OpenGL usage be upgraded to use OpenGL 3 or 4. Although I am going to remove as much deprecated functionality as I can (and not add any more), it is not urgent to eliminate all of the deprecated functions.

I have a hard time imagining that the compatibility profile will ever disappear because there is 20 years worth of OpenGL software people will still want to run.

Maybe there is something you can do about that “double-sided” shading issue on various nVidia cards ?
Or is the problem only on nVidia’s side, disabling some openGL fonctionnalities ?

Some suggestions right of the bat for truly (day-to-day-) viewport enhancements (and not just eye candy):

Texture mode improvements 1 - visualization of non-uv mapped image textures. Changes to the mapping of the texture space is a very ad-hoc trial and error affair currently.

2 - visualization of non-image textures in the 3d textured view (a.k.a shaders)

Deprecated opengl and performance issues
3 - removal of deprecated opengl functions that severely hinder performance of the textured view on ATI cards (performance of the textured view is abysmal on these cards). Image textures cause a major slowdown in performance. For example, try the goose model used in “Project London”: http://projectlondonmovie.com/archives/portfolio/project-london-blender-rigs

This also affects Nvidia cards, but not as much. Still, I feel textured mode performance could be much improved if old, non-hardware accelerated opengl calls were to be removed, and replaced with a modern approach in opengl code.

4 - removal of deprecated opengl functions that hinder performance on nVidia cards. Currently, on nVidia consumer cards double shaded lighting on polygons destroys the viewport performance. Turning off double shaded lighting helps, but Nvidia users should not be forced to turn this off for each individual object to obtain reasonable viewport performance.

5 - On ATI/AMD cards selection of objects in the 3d viewport slows down to a crawl or worse when dealing with semi-complex scenes. With multi-million poly scenes this can mean having to wait for up to a minute for Blender to resolve the selection. Psy-Fi developed an occlusion patch that resolves this, and I feel you should contact him about this. Please read up on this matter in this thread: http://tinyurl.com/7v2sqcs
And, by the way, it also improved selection speed on Nvidia cards I tested (even a Quadro 2000).

General viewport workflow improvements
6 - in wireframe mode: the possibility to assign different wireframe colours to any object in the 3d view. In addition, an option to assign an arbitrary wireframe colour to all objects on a layer. This is a sorely missed feature for architectural visualization and when working on very complex objects and scenes.

7 - an option to apply viewport settings to any selection of objects. Currently, only one(!) selected object at a time can be assigned a different view mode. This is solvable with python, though it would be extremely convenient again for more complex scenes. Also an option to change view port mode settings for all objects on a selected layer. (For example: layer 0 --> wireframe; layer 9 --> solid mode; layer 5–>textured mode)

8 - performance is very important. VERY important. By performance I mean:
a) speed of the opengl view
b) visual quality of the opengl view
Blender is lagging behind compared to the major commercial applications. Points 3, 4 and 5 exemplify the issues in relation to speed issues on all consumer graphics cards that are currently available. Let me repeat this: there are issues on all graphics cards at the moment, which is an insane situation. This must be rectified.

9 - slowdown of the viewport when drawing control objects. Armature controls for animated characters slow down the view too much, in my opinion.

10 - the drawing of selected objects impacts the performance of the viewport quite a bit.
I am not sure if this could be optimized. For example, the furry ball object in my 7970 test thread shows that viewport performance drops by almost 50% after selecting the object: 96fps non-selected, 50fps after selecting the object. (http://tinyurl.com/7j74ghw)

That’s enough for now :wink:

jwilkins, I am truly happy to see someone taking on the task of improving the current 3d viewport. I just hope you will address (at least some of) the above-mentioned issues as well as adding ‘eye candy’ - in my opinion eye candy is nice, but a fully featured workhorse of a high-performance opengl viewport is far more important at this time. Perhaps both can be combined in some way.

Good to see you stating this - please check which deprecated functions affect Blender’s viewport performance on ATI/AMD and Nvidia cards. Those are urgent, in my opinion.

This sounds like a wonderfull idea. The viewport performance is something I sorely need.
I’m also very interested in the shader idea. I have a few ideas on how to put those to use, but I guess we’ll see about that somewhere down the road.

You’ve got a lot of work ahead of you. But you’ll be making a lot of people happy. Good luck!

Thank you @JWilkins
I hope your efforts & work bring Blender closer to the viewports in Maya & 3DS Max, which is impressive IMO

Maya:

3DSMax:



I agree that viewport/3d performance in all views (not only textured but also solid/wireframe and when selecting vertices/faces/edges in edit mode) is very important and improving it should be the top priority. In local (outside BA, in my language) discussion boards it is probably the second most common complaint about Blender, after the “radical” UI compared to other programs.

I don’t know if these improvement would apply to scuplting too, but I guess they would make people into it (I’m not one) very happy.

I think this is a great project. I’ve waited for it for a long time :slight_smile:

Performance optimizations are really welcome, also because with the new bmesh there has been another drop (the first was with the new 2.5 ui) in performance.
On a scene with a complex character in Tube, framerate with the highres model/rig went from 8fps to 6fps. This is halved if I enable playback in all animation editors.

How much performance increase can we really expect? I’ll gladly test your branch when the time comes :slight_smile:

As far as the configurable viewport, this is even a greater idea. Have a look at this image:

http://dl.dropbox.com/u/17486466/gilga.jpg

This is the scene I’m talking about. ATM the reflection is a live copy of the rig, which as you can imagine makes thing rather slow to work with, but still necessary.
Do you think it would be possible to achieve such a thing with your viewport fx?

Thanks again.

.Gian

the 3d widget would be nice to FX a bit :slight_smile: make handles more interactive, possible to select two axis (clicking in between) also have more info about rotate,translate, and scale at cursor position when 3d manipulate. (before we had a classic > degree drawn how far we rotate the object and in what axis).

I think Softimage has teeeh most impressive 3d viewport. Super fast and nice design.

Just a reminder, & food for thought:

When comparing viewport performance and features with Autodesk products, you must remember that Autodesk makes no guarantees that their software will run on “unapproved” hardware… and noticeably absent from ADSK’s “approved” hardware list is any mention of any NVidia GTX or Geforce, nor ATI/AMD Radeon, none, nada. No consumer grade video card is listed as “approved hardware” on any of ADSK’s 3D DCC apps.

It’s all Quadro’s and Fire Pro’s… so ADSK’s canned response to issues with running their software on consumer grade video cards is basically, “We’ll help if we can, but you’re using un-approved hardware…”

This, of course, is not a “customer support” stance that BF is in the position to take, with the vast majority of users employing consumer grade hardware.

6 - in wireframe mode: the possibility to assign different wireframe colours to any object in the 3d view. In addition, an option to assign an arbitrary wireframe colour to all objects on a layer. This is a sorely missed feature for architectural visualization and when working on very complex objects and scenes

Good Idea.

2 main objectives:
Texture viewport - handling images with alpha channel - if there’s alpha channel, it should be transparent on the viewport.
Maya is a really good example for handling image textures on viewport:
https://lh5.googleusercontent.com/-C_o08pEElac/T6fxaXJgOaI/AAAAAAAABLY/WBdgVKRNZps/s671/AlphaTexture.jpg

Hidden line viewport - the ability to see the background through the wire, but it still blocks a wire behind another wire.
Makes modeling by image easier with wires.
Here’s Lightwave’s Hidden Line viewport:
https://lh6.googleusercontent.com/-gQRoUo41f-I/T6fxaY6tF2I/AAAAAAAABLU/ZyE6xmWeIAw/s589/HiddenLine.jpg

Herbert123, I really appreciate you taking the time to write that up. I was aware of the problems with double sided lighting and GL_SELECT rendering mode. That is the kind of deprecated functionality I was definitely going to remove, along with all instances of the glBegin/glEnd regime (as much as I really love its ease of use ;_; ). However, at this point I’m not sure how realistic it is to remove all deprecated functionality and behavior. I see myself as setting the groundwork for being able to support both OpenGL 1&2 for legacy cards and OpenGL 3&4 for new cards.

I know people worry about “eye candy” vs. performance. The two are truly often at odds. But the way I see it, if everybody’s typical workloads are running at 200fps then I have gone too far to one side of this equation :slight_smile:

I have a couple of mantras I repeat that guide my design:

  • visualizations are not materials
  • visualizations are not eye candy

The first is in response to an early argument that people should use Blender’s material system and the GLSL viewport mode to create visualizations. Where a “visualization” is something you’d apply to an object to help you understand it better, NOT something you need to be able to render.

The second is in response to those who seem to believe that wire frame, flat shading, and Gouraud shading are good enough for editing 3D objects and anything more is eye-candy. This isn’t 1996. There are any number of possible ways to draw objects that are not just there to be sexy. Ambient occlusion lets you see an objects shape in a way that is telling in a different way than Gouraud or Phong shading. Being able to see shadows lets you understand how the scene will look in real time without hitting render over and over. A cavity shader gives you a better feel for what your sculpting strokes are actually doing.

Saying the “visualizations are not materials” frees me to work solely in terms of what performs well in OpenGL and not worry about the renderer. I do not have to be able to port between FX and Materials, they can live in their own worlds. It may be bad for the user experience, because you now have two ways to control what appears in the viewport instead of one, but it is good for performance.

Saying that “visualizations are not eye-candy” reminds me that what I do needs to be flexible enough to support fancy stuff and that fancy stuff is not just showing off. I cannot anticipate all the useful things people will want to do, so I should not just choose a few of modes to hand down from on high and etched in stone tablets.

(People also have a tendency to think I spent weeks implementing some fancy feature when I actually spend half of an afternoon. They especially think this when I’m not working on their particular favorite feature :wink: