Autumn time is thinking time

Hey,

Sometimes you just have to think. Do you know that feeling? I browsed thourgh different papers regarding remeshing and thought why it always needs to take ages (up to 2 minutes) to remesh a 100k poly mesh.

Beside that, most of the papers suggest a really complex approach, like using spectral harmonics (what the heck is that?).

So I took some time and thought about different approaches. I like the shrinkwrap approach some artist mentionen in the blenderartists.org forums. It’s fast and easy to implement. Well, the only thing to verify are the quality of the results.

Let’s see how that turns out

Decimate modifier

Hello,

Since I made some research for some paper I stumbled about the decimate modifier in Blender. I tried the well known Stanford Bunny as a test object. It tturned out to fail almost completely and I looked for other libraries. Take a look at qslim, a nice GPL/LGPL (Blender Open Source compatible license) application.

After I integrated the library into Blender, it was time to compare the results: Decimating a 70k object down to 100 faces.

Well the results are pretty clear, aren’t they?

Fluidcontrol in trunk!

Hello!

I haven’t posted anything recently since I’ve been really busy getting fluidcontrol code from branch into trunk. Since the 2.48 release isn’t too far ahead, I took some time to polish the outstanding issues.

Since subversion revision 16652, the fluidcontrol branch is now merged into trunk!

Thanks again to Nils Thuerey who contributed the code!

Wind + effector force update

Hey,

I took some time to take a look at the effectors. After speaking with Janne (jahka, particles creator), we decided to unify and enhance it.

So this are the enhancements so far:

• Wind got ‘noise’ option
• Deflectors can hide effector force now -
  even realtime in 3dview using ‘continues physics’ option (Example blend file: Hidden wind)

Interesting thing: This two options, were one of the seven highlighted big features in Maya 2008!

Ah wait - I even extended the wind feature having the ability to specify the absorption value of each deflector: So 3 deflectors with 10%, 43% and 3% give a total absorption of 99,87%.

UPDATE:

You can download a high quality version of the demonstration video here: Wind collisions example (21.34 MB)

win64 bit in trunk!

Hello,

Yesterday, I commited my win64 changes to trunk. That was only possible thanks to your great support and donations!

You can now compile blender in a 64bit windows environment using cmake:

cmake -G "Visual Studio 9 2008 Win64" .

Then you can easily open the project in Visual Studio and compile it.

Have fun!

Daniel

First win64 testbuild available [update]

Hey,

I just uploaded the first (un)official testbuild into the download section. It should also have OpenMP enabled.

Please test it for bug/crashes which are not in the normal blender svn trunk version, thanks!

Here’s a render compare which shows that the renderer should work fine:

Known Problems:

• There is a crasher with one of the BBB files (tree_trunk/04.blend), but that is Windows related in general

  UPDATE:

• The builds which I get from Vista64 are not XP64 compatible since they seem to link to 32bit libs, even in a 64bit build environment. Since I have no XP64 I have yet to think how to sort out that issue.

Algorithm challenge: (Approximate) Nearest Neighbour

Hi all,

I just took this day of trying to make a benchmark for fast Nearest Neighour algorithms (I’ll choose the fastest one for the new project). For that purpose, I downloaded and integrated the Stann library into blender. The results are quite disappointing for my sample data set:

• static_chan: 1.923355
• sfcnn_ip: 1.436582
• dynamic_sfc: 3.789894
• sfcnn_op: 1.087444
• blender internal kdtree: 0.008079

So basicly the inbuild kdtree beats the Stann library or the kdtree did not work. Since I am not satisfied with the speed results, I challenge everyone to see if you can bring up a faster “(Approximate) Nearest Neighbour” implementation.

The data set I use for verification is this (C code):

int min = 0, max = 10;
int grid = 500;
float width = (float)((float)(max - min) / (float)grid);
 
// init data set
for(int i = 0; i < grid; i++)
{
	for(int j = 0; j < grid; j++)
	{
		for(int k = 0; k < grid; k++)
		{
			Array[(i*grid*grid) + (j*grid) + k] = float(i*width, j*width, k*width);
		}
	}
}

I am searching normally for the 30 nearest neighbours of an arbitrary point in that Array-set.

Good luck!

Fluid control: Negative forces

Hey,

I took some time to make it possible to use negative attraction forces possible. It can be used to get some object “feared” by the water, or to get some explode effect. I also made start and end time working

Here some example with ipo controlled positive and then negative forces (made by nudel):

http://wxtools.com/wp/wp-content/uploads/2008/07/magic1.flv

Rendering works

I made another patch which made the renderer working for large scenes / blendfiles. As a test-case I used the Big Buck Bunny production files which are known to be quite memory intensive.

The remaining problem is if the patch is allowed to go into Blender svn trunk. I am not really satisfied with the quality and the approach (alot of ifdefs for the long / __int64-case) and would like to talk with other Blender developers about the issues.

Update: After taking a look at the finished render, I thought to me: “Never forget the strands” - I just overlooked the strands.c sourcefile and got this funny picture:

UPDATE: Actually, the topic is not quite true. A specific scene file from BBB crashes that blender version. The most weird thing is that it crashes in the render code after having all layers with big RAM requirements rendered. So i think that the error is elsewhere. I’m digging

I also like to give some good news which is that I successfully enabled OpenMP within the Win64 builds (not yet for download).

UPDATE 2: The crash turned out to be a general render bug not related to my win64 version I am yet waiting for it to be solved in svn!

Fluids working

A quick note out of the dev lab: I just verified that Blender Fluids can use more than 4GB ram on a win64 plattform (after a little fix which I commited to svn).