#### Archived

This topic is now archived and is closed to further replies.

# Metaballs - Normals

This topic is 5764 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Yes, I've done it!
If you look up the previous piece of code I posted, you'll see - with x&z's and + with the y's.
I also saw it: very late . This was my problem with the implementation of the new metaball normals!!!

So I've done it, but still running 20FPS (100% software rendered).

Here's the screenshot:

Here's the demo: 3ddemo_metaballs.zip

(ps: Also improved my homepage a little)

Edited by - baskuenen on May 26, 2000 2:12:07 PM

##### Share on other sites
Your metaballs are a whole lot more impressive than mine.

20fps in software mode, I think you should be proud of that. Have you tried the optimizations that I did?

What size do you use for you energy field? In my current version I use 48*48*48.

Could the smooth specular highlights be the result of Phong lighting? I had to turn off specular lighting on my balls because they looked horrible.

- WitchLord

##### Share on other sites
Thanks,

I haven''t optimized the force grid yet. I was thinking about it, but have not come up a solid algo for this...I''m really interrested in your optimizations!

I must admit I''m using a 32*32*32 grid only.

And yes, I managed to implement a fast phong mapping algo. (It''s no OpenGL or DirectX - so you can cheat a little with this)

I like - you like it! You answering all my questions, and I never could answer yours, was starting to bug me.
I always said to myself: If you can do metaballs, you''re really good! Now I can do metaballs, and I feel good. If you can do metaballs like WitchLord or Hans: You''re also a superb programmer! Guru is the name here!

I''m just home - back from the cafe (burph) - Need some liquid now...

##### Share on other sites
Well, I only made a simple optimization, yet the performance was increased by 367%.

What we must recognize here is that the only energy values that are needed are those that are really close to the surface of the balls. In my optimization I don''t compute the values that are too far away from any of the balls. It can maybe be optimized further by not computing the values that are inside the balls as well.

Anyway you can see my optimization in the source code, it is really simple so you shouldn''t have any trouble implementing it in your own code.

- WitchLord

##### Share on other sites
WitchLord:
While looking through your code I noticed it looks simple and clean. Mine still is a bit messy with lots a pointers and stuff.

I''m not re-normalizing the added normals. Is this really needed? It will improve performance a bit.

Is there a precise threshold value for the energy field optimization?

##### Share on other sites
Just for the record: Here''s my metaball vertex normal calculation source:

void __fastcall CalcVertexNormal(PVERTEX pVertex){	float x = pVertex->x;	float y = pVertex->y;	float z = pVertex->z;	float dx1 = (x-tx1);	float dx2 = (x-tx2);	float dx3 = (x-tx3);	float dx4 = (x-tx4);	float dy1 = (y-ty1);	float dy2 = (y-ty2);	float dy3 = (y-ty3);	float dy4 = (y-ty4);	float dz1 = (z-tz1);	float dz2 = (z-tz2);	float dz3 = (z-tz3);	float dz4 = (z-tz4);	float n1 = dx1*dx1 + dy1*dy1 + dz1*dz1;	float n2 = dx2*dx2 + dy2*dy2 + dz2*dz2;	float n3 = dx3*dx3 + dy3*dy3 + dz3*dz3;	float n4 = dx4*dx4 + dy4*dy4 + dz4*dz4;	n1 = MB_SIZE*MB_SIZE / (sqrt(n1) * n1);	n2 = MB_SIZE*MB_SIZE / (sqrt(n2) * n2);	n3 = MB_SIZE*MB_SIZE / (sqrt(n3) * n3);	n4 = MB_SIZE*MB_SIZE / (sqrt(n4) * n4);	pVertex->nx = dx1*n1 + dx2*n2 + dx3*n3 + dx4*n4;	pVertex->ny = dy1*n1 + dy2*n2 + dy3*n3 + dy4*n4;	pVertex->nz = dz1*n1 + dz2*n2 + dz3*n3 + dz4*n4;}

##### Share on other sites
Normalization of the normals are only needed if your lighting code requires it. For both OpenGL and Direct3D the
normals must be unit length, otherwise you''ll get strange lightvalues. If you try normalizing the normals, you''ll see that it doesn''t make a lot of difference to the performance.

I noticed that you have an extra step when computing your normals:

n1 = MB_SIZE*MB_SIZE / (sqrt(n1) * n1);

Is this necessary? Does it give you better appearance of the lighting?

The threshold I use in my optimizations is the distance from the center to the surface if all balls was on the same spot.

- WitchLord

##### Share on other sites
Well I tried adding that step in the normal computations myself and it does look better. I also tried with this:

n1 = MB_SIZE*MB_SIZE / (n1 * n1);

And that does also look right. So which is it? I''ll have to do some testing, I''ll add some user interactivity to my program so that I can do some tests.

- WitchLord

##### Share on other sites
I''m using this extra step for some optimization.
I''m using floating point:
- FDIV costs 17 instructions
- FMUL costs 3 instructions
This is not entirely right, because floating point functions can be interleaved with integer functions, but thats not the case in this function.

If you are going to divide multiple numbers by the same value, it''s better to divide once, and then multiply the rest! If optimized in assembly the FMUL''s clock count could be reduced to 1, and can interleave each other! (the FDIV''s cannot) But that''s all another topic, and you probably knew most of it.

So the extra step is for optimization only.

> The threshold I use in my optimizations is the distance from the center to the surface if all balls was on the same spot.

Good point, that''s the threshold!

Then: If you want the minimal value for a metaball optimization: use the distance from the center to the surface if just one ball.

• 17
• 19
• 23
• 10
• 21