Pixar OpenSubDiv

I know it´s been written on the wall, many times here.
But here´s a impressive video with OpenSubDiv in Maya :frowning: Bleh. Anyways.

It´s Open Source, I think. Ton made them fix the license! Brecht had said on the mailing list IIRC that he wanted to have it working with cycles for siggraph.

The sooner we can get it in blender the better :stuck_out_tongue:

What is kinda neat is that , the sound of it it sounds like the model is subsurf´ed on the GPU, which should maybe mean that it´s already there for Cycles to render? … maybe it needs to be BVH builded and sent to GPU anyways. I dunno.

Yes, the opensubdiv does look really cool :slight_smile:

One thing I thought was funny, was the presentation guy saying how an open pipeline was important to Autodesk.

I thought an open pipeline meant being able to have your workflow go between different programs as you needed to achieve your ends (such as using the Autodesk .fbx file to transfer data, which would require Autodesk to detail the spec, both text and binary)

I didn’t think it meant using openexr, opensubdiv or other open things to do things for you since they are are already half done :stuck_out_tongue:

I guess OpenEXR does count for an open pipeline, I guess I’m saying an open pipeline doesn’t seem to really be autodesks main priority.

yeah, I shrugged a bit at that intro part. But then he said, they contribute. Do they? to the repos. if so that´s a bit cool at least.

*** the day autodesk commits to blenders source code :stuck_out_tongue_winking_eye: ***

To set expectations for OpenSubdiv in blender, here are some facts about today’s opensubdiv:

  1. it only handles manifold surfaces via a half-edge representation (though they are supposedly working on this), blender BMesh is a non-manifold capable implementation of radial edge.

  2. because it is a GPU subdivision implementation, it doesn’t fit into the middle of a CPU modifier stack, only at the end

  3. the process of generating a GPU-renderable mesh is slow, and currently needs to be redone every edit. This means it’s only practically useful for the animation part of a workflow today.

Davesf; what about Cycles though, Brecht talked about the possibility about Cycles using OpenSubDiv for its rendering subdivision surfacing and leaves me to wonder if the old implementation can be used for the viewport and be replaced with the OpenSubDiv version when the scene is transferred to the engine.

As for its use during mesh editing, it does seem like a bum deal right now when it comes to its existing weaknesses, but it’s likely that Pixar and the various studios and software vendors using it are aware of that.

Wouldn’t the improvements planned for Blender’s underlying structure also potentially help solve those problems? Maybe not directly, but maybe through cleaning up and updating it could make the whole system easier to upgrade and tweak, right? That is, if I understand what the depsgraph changes mean for potential future developments.

Can’t comment on OpenSubdiv just yet, but give me a few minutes and I’ll watch the video :wink:

EDIT - Okay, OpenSubdiv is officially freaking brilliant :eek:

@AceDragon - To consider what OpenSubdiv could do for cycles, let’s consider what it is. OpenSubdiv is a screen-space GPU subdivision surface tessellation engine – that is, it is a GPU program which accepts a subdivision surface control mesh, and adaptively subdivides the limit surface so that features near the camera receive more polygons than features far from the camera. None of that will change the speed of tracing a ray in Cycles, which is a large amount of it’s work. OpenSubdiv could provide some render-scene-setup-time and memory consumption improvements – because adaptive tessellation on the GPU is certainly faster than non-adaptive tesselation on the CPU. However, for long renders, setup time is a pretty small part of the overall render-time, so I wouldn’t get too exited. This could be a big performance win for Cycles interactive progressive preview rendering, because there the render-times are short and setup time can be a longer portion of total time.

@Philippe - There is nothing about blender cleanup which would affect the OpenSubdiv limitations I mentioned, because they are part of the OpenSubdiv code. There is effort going on to improve OpenSubdiv code, so future versions of it might support non-manifold surfaces and/or support incremental updates to the opensubdiv FAR (feature adaptive representation). However, it’ll probably be quite a while.

In addition to CUDA, doesn’t OpenSubdiv have both C++ and OpenCL backends, both of which will happily run on CPU and could return mesh data to Blender? It could still run on GPU when it’s at the end of the stack.

I’m not sure what you’re referring to here. If you mean returning the subdivided limit surface, the Maya presentation demo, the OpenSubdiv viewer and the Modo implementation seem plenty fast to me.

Also, while it will certainly not help a great deal with Cycles speed, it can certainly help with memory consumption on GPUs.

Aaah, I see - thanks for the info! Guess I must’ve misunderstood/misread your original post :o

That is a good point, however, there are limits to what you can do with screen-space adaptive subdivision as a mid-stack modifier for offline rendering purposes, because the number of faces it generates is camera-view dependent.

Consider particle-emitters. If you make cube, added an opensubdiv modifier, then a particle-emitter emitting per-vertex, opensubdiv would make fewer vertex-emitters away from the camera. This will totally bork your particle simulation. For example, if the camera moves, the number of subdivisions would change, causing the number and position of emitters to change, causing particle emission to inconsistently jump all over the place.

It might be reasonable to have adaptive subdivision ahead of some modifiers, like boolean, or a deformation cage.

I’m not sure what you’re referring to here. If you mean returning the subdivided limit surface, the Maya presentation demo, the OpenSubdiv viewer and the Modo implementation seem plenty fast to me.

OpenSubdiv can very quickly produce the view-dependent tesselation of the limit surface from a FIXED topology control mesh representation it calls the FAR (feature adaptive representation). If you change the control mesh topology atall* (aka, add or remove faces), it has to do an expensive re-calculation to rebuild the FAR. They say in the docs they are working on ways to allow incremental updates of the FAR, but it’s a hard problem.

Also, while it will certainly not help a great deal with Cycles speed, it can certainly help with memory consumption on GPUs.

As the last element in the stack, yes. An adaptive camera-space tessellation can have fewer polygons than the non-adaptive representation, saving memory during cycles rendering.

Here were some notes made by Brecht about this feature.
http://lists.blender.org/pipermail/bf-committers/2013-July/041366.html

Now according to my opinion, I consider that OpenSubDiv is awesome for real time applications but limited only on organic models.

It’s something like having a very high detailed creature and OpenSubDiv will work something like “level of detail” rendering, this brings “Sculpting” to my mind mostly.