ZGameEditor forum

I stumbled onto this Meta-ball page [ http://en.wikipedia.org/wiki/Metaball ] and thought to try it in ZGE,. have a looksee,.

Ville why do the sphears "pop" in and out when they are not overlaping? I am thinking it is the Combine,. but should it not work even if they don't actually touch? If it could, this looks like it would be useable for some nice meta-blob action.

LOL I hate you this was the one I was studying on!!! It should have been a BIG surprise if I was able to get them running on a decent framerate (actually it can be done but the whole thing is about 15 FPS when you are moving 4 balls...)

BTW: It's quite important: how many triangles is the teapot in the shader demo???
I can only see his "meshdata" property being about 373000 but what does it means exactly?
I'm calculating the maximum precision I will get from metaballs if I was using vertexshaders instead of simple CPU power yes, there's a way of using shaders instead of CPU and it seems to be a killer feature

And this is the last question: is it possible to permanently modify the mesh using only the vertex shaders? I suppose answer is "no"

some teapot info.s

http://www.sjbaker.org/wiki/index.php?t ... The_Teapot
http://en.wikipedia.org/wiki/Utah_teapot

edit - if you look in the GREEN window in ZGE you can get mesh triangle numbers,. it say the teapot it 40k polys. (or just switch to wire mode and count them )

don't b hate'n!
Great minds think alike,. . I am sure you can find some cool ways to optomize and better this,. it was just a cool realization for me that the refreshContent component is not nessissarily a speed killler and can be used to good effect. However, doing the math in the GPU is a great idea,. I was wondering about GPU phyiscs :S can you pass values to the vertex shader and get results back ?? Must be some way as I hear tell of ppl using them for sound,. .

Haha, I didn't think that the implicit was fast enough for real time but this actually looks pretty good!

I'm no expert on shaders but from what I understand is that when people use shaders for numerical calculations (sounds etc) they write fragment-shader and render to a texture. This texture is then read back to the main cpu as an array of numbers and contains the result of the calculations. And sorry this can not be done with ZGE currently.

I don't think that the spheres should interfere when they are not touching but maybe a high blend value can cause this. I'm not sure, it was a while ago I wrote that code.

Not exactly metaballs ( splines & physics ), but had to think of Takahashi's upcoming game Nobi Nobi Boy.

well that one looks interesting,. quite strange, and interesting,.

looks like a metaball type adaptive mesh system,. just with balls all along those tubes,. not sure what that game will b about,. . eating farm animales?

I think we can achieve some intersting effects with the implict mesh system,. although the poping in and out of the meshes that dont touch is a problem,. unless I find a nice well constrained way to hold my object together?,. springs would be best. but alas no physics system,. . I will ponder it more using what we have,. .

I read about that game in EDGE-magazine. The article said it was still little more than a tech-demo, and that the actual gameplay was yet to be decided. Seeing the video I've got to say I think it looks very cool in motion and could be real fun to play if they get it right.

Please post a picture or zgeproj that illustrates the popping-problem, I'm not sure I've understood what you mean.

Problem is: create a mesh; meshproducer: Mesh implicit -> implicit combine

Try combining 2 spheres that does not touch. The result is that only one sphere is drawed. This is BAD because you can't just update one mesh for creating metaballs since you only get one sphere.

The logic error in this is here in the code
by using this you are assuming that there is only one surface with positive/negative values crossing! But you might find lots more of them!

I have found a seems-to-me good and really simple implementation of the marching cubes here: http://www.sulaco.co.za/opengl_project_metaballs.htm
It seems to be checking the whole space, and it does not seem slow or whatsoever; I think we must make use of this kind of alg and set manually the right bounds in MeshImplicit component.

Oh, I see. Yes the current implicit surface algorithm will only render a single surface. I assume this is why many meta-ball demos always keep the spheres in contact. I will read that article/source you've posted kattle, let me know if you experiment with it and find something useful.

Have you wrote the Implicit algorithm all by yourself? Because I'm sorry but it seems really obscure and redundant to me. I have understood what the code does but I feel there is just too much stuff. IMHO we should rebuild it almost from scratch, mainly for what regards the polygonizing process. I also feel that the TriangleSize property should be "rebind" to let there be GridResolution or something like that (the resolution of the grid used for creating the cubes). We will gain in speed by forcing the user to set decent values for the bounds.

Attached there is an example of the reason re-writing is needed:

Nothing fancy: A sphere of diameter 0.3, 4k triangles, offsetted by 2 on the X axis.
It won't be rendered.

If it is rendered, just move it a little bit until the "random()" used by the function that finds the surface fails finding it.

Make it better! faster! stronger!

All good game systems need more wobbly balls,. .

Hey jph,

You forgot harder!

The code is translated from C: http://www.unchainedgeometry.com/jbloom/papers.html

As far as I know this is a standard marching cubes algorithm. I actually did tons of research (bought two books on this topic alone) before attempting this, but I wanted to start with an algorithm that had source code available and this was the best that I could find. I found others that were massively complex and dependencies to large graphics libraries.

There are quite a few algorithms that render only a single surface so this one is part of this family. One problem I foresee with multiple surfaces is that today the TMesh component is a single mesh (set of triangles). So a algorithm that generates multiple meshes perhaps cannot be a MeshProducer, instead it would be a Render-component that evaluates the function every render.

I'm not that happy with the current implementation either, this is why I have not made any changes for so long. So I welcome any suggestions! Particularly if there is a short and easy to understand source code available.

Here are some links I've found earlier:
http://herakles.zcu.cz/~cermakm/
http://www.visgraf.impa.br/Projects/simple/
http://www.crd.ge.com/esl/cgsp/projects ... march.html

actually if I'm not wrong the algorithm I've linked to before generates only ONE set of triangles, even if it is true that the triangles are not linked each other! I mean, that should not be wrong: do the triangle need to share vertexes? AFAIK it is not needed so you will get a single mesh that resemble more objects. Give a look at the example, is somewhat simple! I post it again for sake of simplicity:
http://www.sulaco.co.za/opengl_project_metaballs.htm

here is some intersting infos,. not realy metaball related but even better in my opinion,. procedural mesh models,. sorta remindes me of NERBS a bit,. but I just point to it for insperation, in the hopes that someone may make more cool stuff for me to use in my gamemakeing endevors,. . cheers.

http://tobw.net/index.php?cat_id=2&proj ... nal+Meshes