Adaptive Subdivision Modifier (in development)

Published by Kernon on April 4th, 2008 in 3D News, Development

Kai Kostack, developer of the awesome Demolition script, is at it again…

During the initial development stages, Kai writes:

I had another strange idea. Now it's the implementation of micropolygons via python. It's probably the worst implementation of micropolygons ever made, because it's so slow and needs unbelievable amounts of memory but at least it works.

Further developments

I did some optimizations for motion blur.

Check this example mapped with depth images:

I just put suzanne there, produced a depth map straight from the z-buffer and then I applied the displacement modifier to it. To be exact two of them because I used two different uv-layers, each for every size. I used this image:

Another example

Render time: 6 minutes for 12,000,000 micropolygons

Not bad for a python script.

First Release (the code has been ported to C and integrated into a test build as a modifier)

This is the first test build (for Windows) and there are a still a few known issues left to solve:

There is no motion blur correction and optimization so far. The modifier is calculated for each subframe for regular motion blur and vector blur won't work at all so far.

When rendering the modifier is always calculated three times per frame, even when vector blur or speed vectors are disabled. i don't know why blender does this, it's strange.

In the viewport on time changes the animated camera position and rotation is somehow always one frame behind. i don't think the modifier is the reason for this, G.scene->camera->obmat simply returns old values.

And some for the end-user invisible hacks were needed to bypass some strange behavior of a meshtool function. I need to talk to some blenderdev about this.

It's slow but it should work.

Download it from graphicall.org

I've created also a patch in case you want to build for your own platform. There is lots of old code in there but I'll clean it up later when the problems are solved.

For more details and to keep track of development, visit the discussion thread.

Related posts are selected automatically based on their content.

23 Responses to “Adaptive Subdivision Modifier (in development)”

Feed for this Entry Trackback Address

1 madman Apr 4th, 2008 at 6:42 am

Great!
Good work!

I waiting for this
2 Jarod Apr 4th, 2008 at 6:49 am

very cool stuff!
3 3sie 3wiel Apr 4th, 2008 at 7:03 am

Berry berry cool mun!
4 LoMac Apr 4th, 2008 at 7:55 am

Interesting.
5 mike pan Apr 4th, 2008 at 8:15 am

Sweet, this patch should speed up large tessellated ocean surfaces significantly.
6 Marcus Apr 4th, 2008 at 8:28 am

I'm not sure if I got the concept of this. What exactly does it, why adaptive? Can somebody explain to me, please?
7 LoMac Apr 4th, 2008 at 9:06 am

I guess it adds more resolution as needed. like if you;re far away it doesn't need so much then as you get closer it increases the resolution of the mesh.
I could be totally wrong.
8 AniCator Apr 4th, 2008 at 9:44 am

What the! That is really cool for big detailed scenes! Maybe you should add a subtractive subsurface function to it too.
9 TX_RX Apr 4th, 2008 at 10:22 am

Now that's an amazing feature! Nice one Kai! I bow to your super skills with Python, man, someone like him will wind up being snapped up by sidefx or autodesk the rate he's producing these great scripts!
10 wayne Apr 4th, 2008 at 11:53 am

is adaptive subdivision actually the same thing as micro-polygon?

how does this specific patch relate to the micro-poly work that was planned for peach?
http://users.pandora.be/blendix/peach_development.pdf
11 Kernon Apr 4th, 2008 at 11:56 am

Sorry folks, I failed to include a link to the discussion thread. It's been added to the article.
12 wayne Apr 4th, 2008 at 12:04 pm

what would be really interesting is magically combining this with the sculpt tools….
kinda similair to zbrush3's HD sculpting

maybe they can do that with project Durian…
13 yokljo Apr 4th, 2008 at 12:45 pm

ooh, fractal suzanne
14 Schnappi Apr 4th, 2008 at 2:14 pm

damn, that sounds like a typical LoD implementation for games.
Im not sure if it is useful at the end for animation projects but still it shows how powerful blender really is. :)
15 Kukanani Apr 4th, 2008 at 3:16 pm

Interesting.
16 roofoo Apr 4th, 2008 at 4:37 pm

@Schnappi: Actually it's the opposite of LOD. LOD reduces poly count as objects get further from the camera. This takes a mesh and adds more detail to the mesh when it gets close to the camera. Big difference.
17 panzi Apr 4th, 2008 at 7:29 pm

Awesome!
For me this is mathemagic.
18 Master Hoshi Apr 4th, 2008 at 10:40 pm

A LOD modifier would be very useful since you could actively decimate. Would probably be slow though.
19 Ataru Apr 5th, 2008 at 12:41 pm

Whew, that's amazing! In theory I like this idea even better than the demolition script. Keep up the good work, Mr. Kostack! I'm downloading it! ;-)
20 Wahooney Apr 7th, 2008 at 11:06 am

Very, very impressive :D

Wants it!
21 mrmowgli Apr 7th, 2008 at 9:25 pm

I like i, sort of like a dynamic LOD? Why not just use a multires and swap out which one is rendered based on distance from the camera?

Also, how about making it available as a Node or letting Weight Paint modify how many polygons are created on a mesh?

mrmowgli
22 ygs Apr 13th, 2008 at 1:31 pm

I hope this will be available for SCULPT MODE TOO !

This would be VERY HELPFUL!

Any hope ?
23 nowherebrain May 3rd, 2008 at 3:31 pm

Well "adaptive" means that it will tessellate where and how you define…could be based on distance, weight paint, edge sharpness, ipo, or any combination..this is my guess. This is how it "should" work….I've not used it though. In any case this is some very nifty stuff…"great work" is a sore understatement here….especially if it was coded by one person…"WOW" is my opinion..getting this to a dll will drastically improve it's speed too.
One question, is it UV compatible….does it preserve UV's?